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1.  INTRODUCTION 


1.1  OBJECTIVES  AND  APPROACH 

The  Weapon  System  phase  of  the  APL  DoD  Weapon  Systems  Soft- 
ware Management  Study  was  concerned  with  specific  applications  of  soft- 
ware design  and  management  to  major  Weapon  Systems.  The  systems  were 
selected  to  represent  a variety  of  platforms  and  major  missions  and  to 
illustrate  all  phases  of  the  Weapon  System  life  cycle. 

The  survey  of  individual  Weapon  Systems,  as  a major  input  to 
the  overall  APL  study,  had  the  following  objectives! 

1.  To  serve  as  a basis  for  understanding  how  and  what  Weapon 
System  software  is  being  or  has  been  developed,  produced, 
deployed,  and  maintained  in  the  user  environment; 

2.  To  serve  as  a basis  for  distinguishing  among  the  large 
range  of  uses  of  software  in  Weapon  Systems;  differences 
in  function,  size,  and  complexity;  and  the  way  these  dif- 
ferences affect  software  problems  and  potential  solutions; 

3.  To  provide  insight  into  the  organizational  relationships 
between  the  Government  Program  Managers,  system  contrac- 
tors, software  contractors,  and  Government  test,  mainte- 
nance, and  training  facilities; 

4.  To  identify  design  and  management  techniques  that  have 
proved  successful  and  that  warrant  more  general  applica- 
tion; and 

5.  To  obtain  opinions  from  key  personnel  concerning  ways  in 
which  the  Office  of  the  Secretary  of  Defense  or  the  Ser- 
vices can  contribute  to  the  improvement  of  software  cost 
and  performance. 


The  survey  of  Weapon  System  software  was  carried  out  through 
the  auspices  of  the  respective  Program  Managers.  System  and  software 
contractors  were  visited,  where  possible,  to  obtain  first-hand  informa- 
tion on  system  characteristics  and  development  methods. 


The  selected  Shipborne  Weapon  Systems  are  listed  in  Table  1-1. 
Two  other  appendices  in  this  study  discuss  Airborne  Systems  and  Undersea 
and  Landbased  Systems.  These  three  appendices  present  more  detailed  in- 
formation than  was  given  in  Section  4 of  the  main  report. 
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TABLE  1-1 

WEAPON  SYSTEMS  INVESTIGATED 


Weapon 

System 

Programs 

Systems 

Status 

DLG-28 

Combat  System 

Tactical  Data  System 
Terrier  Weapon  System 

Deployed 

DDG-9 

Combat  System 

Tactical  Data  System 
Tartar  Weapon  System 

Deployed 

DLGN-38 

Combat  System 

Command  and  Control  System 
Sensor  Interface  Data 
System 

Tartar  Weapon  System 
Gun  Fire  Control  System 
Underwater  Fire  Control 
System 

Production 

CV 

Tactical  Data  System 

Aircraft  Landing  System 
Missile  Fire  Control 
System 

Deployed 

AEGIS 

AEGIS  Weapon  System 

Develo pment 

The  individual  discussions  vary  in  detail  because  of  the  dif- 
fering stages  of  development  of  the  different  systems.  The  following 
kinds  of  information  were  sought: 

1.  General  System  Description:  A sufficient  description  to 

provide  understanding  of  the  overall  system  mission  and 
requirements  and  the  operating  environment  of  the  embedded 
computer  system; 

2.  Computer  System  Architecture:  The  selection  of  computing 

equipments  and  their  operating  relationships,  including 
the  functions  allocated  to  each  computational  unit; 

3.  Computer  Program  Architecture:  The  structure  used  in  com- 

puter program  design  throughout  the  system,  including 
allocation  of  functions  to  elements  of  the  computer  pro- 
grams ; 
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4.  Software  Definition,  Design,  and  Implementation  Methods: 
Techniques  used  in  software  system  design  management  and 
control,  especially  those  which  have  had  apparent  success; 

5.  Software  Validation  and  Integration  Methods:  Management 

techniques,  testing  tools  and  techniques,  and  facilities 
used  in  software  quality  assurance; 

6.  Software  Acquisition  Management  Organization  and  Methods: 
Methods  used  by  the  Government,  system  contractor,  and 
software  contractor  to  manage  the  process  of  software  de- 
sign and  validation;  and 

7*  Operational  Software  Maintenance:  Approach  used  or  plans 

for  transfer  of  developed  software  to  Government  control 
for  lifetime  support  and  maintenance. 

Each  paragraph  in  the  Highlights  section  for  each  Weapon  Sys- 
tem is  followed  by  one  or  more  designations  in  parentheses  (e.g.,  (SE1)). 
Such  a designation (s ) indicates  the  APL  recommendation(s)  from  the  main 
report  that  correlate  most  closely  with  the  particular  highlight. 


1.2  SHIPBORNE  SYSTEMS 

The  current  and  projected  Fleet  deployment  of  ships  either 
carrying  digital  equipment  or  planned  for  digital  systems  includes  12 
carriers,  29  destroyers  of  the  DDG  class,  7 cruisers  of  the  nuclear- 
powered  DLGN— 36  and  DLGN— 38  classes  (to  be  redesignated) , 30  cruisers 
of  the  DLG  class  (to  be  redesignated),  and  a unique  cruiser  (CGN-9). 

Four  of  these  ship  classes,  together  with  the  Navy's  newest 
air  defense  combat  system  (AEGIS),  were  selected  for  study  since  they 
represent  successive  phases  in  the  evolution  of  digital  Weapon  Systems 
in  the  U. S.  Navy. 

DLG-28  (USS  Wainwright)  exemplifies  the  currently  deployed 
Naval  Tactical  Data  System  with  the  recent  addition  of  digital  fire  con- 
trol capability. 

DDG- 9 (USS  Towers)  represents  recent  updating  of  selected 
Guided  Missile  Destroyers  with  a digital  Tactical  Data  System. 


DLGN  38  (USS  Virginia)  is  one  of  a new  class  of  Guided  Missile 
nuclear  frigates  now  under  development  and  using  an  extensive  central- 
ized complex  of  modular  AN/UYK-7  computers. 


1-3 


THE  JOHNS  HOPKINS  UNIVERSITY 

APPLIED  PHYSICS  LABORATORY 

LAUREL,  MARYLAND 


CVAN-68  (USS  Nimitz)  is  the  most  recently  commissioned  air- 
craft carrier  with  digital  Tactical  Data  and  Aircraft  Control  Systems. 
Digital  missile  fire  control  systems  are  also  installed  on  certain  ships 
of  the  CV  class. 

A Strike  Cruiser  was  selected  to  represent  a possible  future 
ship  outfitted  with  the  AEGIS  Weapon  System. 

Figure  1-1  represents  the  relative  complexity  of  digital  sys- 
tems in  the  selected  ships.  The  figure  shows  major  computers,  periph- 
eral memory,  and  operator  consoles.  These  are  segmented  by  the  basic 
functions  of  a combat  system:  target  detection,  combat  direction,  weapon 

control,  and  operability  testing.  The  memory  available  to  system  compu- 
ters is  represented  by  the  vertical  scale;  processors  are  represented 
by  symbols.  The  number  of  operator  consoles  involved  in  these  functions 
is  also  represented  by  symbolic  blocks.  The  figure  shows  the  growing 
trend  toward  automation,  particularly  in  the  functions  of  detection  and 
systems  test.  This  trend  is  accompanied  by  a reduction  in  the  number 
of  operators  required  for  manual  tasks  of  target  position  plotting. 

Table  1-2  summarizes  the  types  of  digital  computers  employed 
in  these  shipboard  systems.  There  has  been  a strong  tendency  to  stan- 
dardize the  computer  equipment  used  in  shipboard  combat  systems.  The 
USQ-20,  CP-789,  and  CP-848  computers  have  been  used  in  a variety  of  ship 
applications.  The  AN/UYK-7  and  AN/UYK-20  computers  implement  more  re- 
cent technology  and  are  designated  by  the  Navy  as  "standards11  for  cur- 
rent and  future  shipboard  tactical  digital  applications. 

DLG-28  (USS  Wainwright) , deployed  in  1966,  was  the  first  op- 
erational ship  to  carry  a complete  Naval  Tactical  Data  System  (NTDS) . 

The  growth  of  digital  capability  in  the  Fleet  from  the  initial  digital 
systems  in  support  of  command  and  control  to  the  present  inclusion  of 
digital  fire  control  has  been  an  evolutionary  process,  resulting  from 
early  pioneering  in  this  area  by  the  Naval  Ship  Engineering  Center 
(NAVSEC) . 


Responsibility  for  acquisition  and  maintenance  of  software  and 
systems  has  been  divided  among  several  participating  organizations  with 
equipment  responsibility  typically  at  NAVSEC  and  software  responsibility 
at  Fleet  Combat  Direction  System  Support  Activity  (FCDSSA) , Dam  Neck 
(DN)  or  San  Diego  (SD).  A significant  part  of  the  testing  of  these  sys- 
tems is  conducted  at  the  Navy’s  Mare  Island  Facility  and  aboard  Fleet 
units . 


Both  digital  hardware  and  software  have  advanced  through  many 
stages  of  development.  The  lessons  learned  within  the  framework  of  the 
NTDS  development  have  led  to  several  generations  of  standard  computers. 
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Fig.  1-1  Comparison  of  Shipborne  Systems 
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TABLE  1-2 

SHIPBORNE  COMPUTERS 


Computer 

Designation 

Word  Length 
(bits) 

Cycle  Time 
(ys) 

System 

No.  of 
CPU's 

CP-642/USQ-20 

30 

8 

DLG-28 

3 

CP-642B/USQ-20 

30 

4 

CVAN-68 

5 

CP-789/UYK 

18 

4 

DLG-28 

2 

CVAN-68 

2 

CP-848/UYK 

18 

2 

DLG-28 

2 

DDG-9 

2 

CVAN-68 

2 

Mk  157 

16 

1 

CVAN-68 

1 (option) 

AN/UYK-7 

32 

1.5 

DDG-9 

1 

DLGN-38 

6 

AEGIS  Ship 

14 

AN/UYK-20 

16 

0.75 

DDG-9 

2 (future) 

AEGIS  Ship 

8 

of  which  the  AN/UYK-7  and  AN/UYK-20  represent  the  latest.  In  a similar 
manner,  standard  displays  have  also  evolved,  with  the  AN/UYA-4  Display 
Group  being  the  latest  example.  Methods  of  programming  have  advanced 
from  the  dedicated  processing  of  the  early  years  to  substantial  amounts 
of  shared-memory  processing  and  some  use  of  multiprocessing.  Recent 
hardware  developments  have  shown  a growing  interest  in  the  use  of  limited 
special-purpose  processing  (e.g.,  microprocessors).  Lessons  learned  in 
these  programs  have  indicated  a growing  need  for: 

1.  Strong  program  management,  from  inception  to  development 
maintenance , 

2.  Detailed  documentation  requirements, 

3.  Standard  high-level  language  development  (CS-1,  CMS-2), 

4.  Standard  equipments,  general  and  special  purpose, 
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5.  Functional  system  segments  and  common  modules, 

6.  Firmly  controlled  interface  specifications,  and 

7.  Rigorous  control  of  testing  and  changes. 

The  trend  in  shipboard  digital  instrumentation  has  progressed 
to  include  digital  fire  control  in  a significant  number  of  our  surface 
combatants.  The  development  of  these  fire  control  systems  has  been  in- 
dependent but  has  made  extensive  use  of  NTDS  equipments  and  technology. 

Implementation  of  Automatic  Detection  and  Tracking  (ADT)  of 
sensor  information  has  received  substantially  less  attention  than  is  de- 
sirable. A requirement  for  identification  friend  or  foe  (IFF)  beacon 
video  processing  was  imposed  on  the  Fleet  during  deployment  in  SEASIA  to 
cope  with  the  heavy  track  load  and  maintain  appropriate  classification 
of  targets.  A number  of  other  systems  are  currently  undergoing  develop- 
ment, selected  elements  of  which  will  be  installed  in  future  ship  im- 
provement programs.  Among  these  are  the  AN/ SPS-48C  radar  and  the  AN/ 
SYS-1  Integrated  Automatic  Detection  and  Tracking  ( I ADT ) system. 

Major  support  systems  aboard  ships  are  also  undergoing  rapid 
change  with  automatic  digital  processing  and  control  providing  the  prime 
forcing  factor.  Among  these  are  systems  for  navigation,  communication, 
and  specialized  functions  such  as  aircraft  landing  control  systems.  A 
major  growth  in  force  and  Fleet  level  coordination  of  command,  control, 
and  communications  (C3)  functions  is  expected  in  future  years. 

Computer  control  of  operational  readiness  test  and  fault  iso- 
lation is  expected  to  continue  to  advance.  Replacement  of  the  analog 
fire  control  computer  with  a digital  computer  has  resulted  in  a major 
improvement  in  reliability.  The  Operational  Readiness  Test  System 
(ORTS)  of  AEGIS  represents  a major  improvement  in  this  area.  Increasing 
development  of  computer-controlled  on-line  testing  is  expected  in  future 
improvement  programs. 

Information  was  gathered  on  shipboard  Weapon  Systems  through 
visits  to  Program  Managers  and  contractors,  as  well  as  through  refer- 
ence to  APL/JHU  personnel  who  have  been  directly  involved  with  asso- 
ciated programs.  The  principal  agencies  visited  are  listed  in  Table  1-3. 


1-7 


THE  JOHNS  HOPKINS  UNIVERSITY 

APPLIED  PHYSICS  LABORATORY 

laurel.  Maryland 


TABLE  1-3 


WEAPON  SYSTEM  PROGRAM  VISITS 


Weapon  System 
Program 

Agency  Visited 

Responsibility 

Date 

(1975) 

DLG-28 

NAVSEA  6541 

Program  Manager  (Terrier) 

3/4 

FCDSSA(DN) 

Development  and  Maintenance 
Agent 

2/11-12, 

3/12-13 

DDG-9 

NAVSEA  6542 

Program  Manager 

3/4 

FCDSSA(DN) 

Development  and  Maintenance 
Agent 

3/13 

Raytheon  Co. 

Software  Contractor 

3/17 

DLGN-38 

NAVSEA,  PMS  378 

Program  Manager 

3/10 

NAVSEC  6172 

Development  Agent 

3/4 

FCDSSA(DN) 

Maintenance  Agent 

3/12-13 

Raytheon  Co. 

Software  Contractor 

3/17 

CV 

FCDSSA(SD) 

Development  and  Maintenance 
Agent 

2/25-26 

AEGIS 

NAVSEA,  PMS  403 

Program  Manager 

2/24 

RCA  Corp . 

System  Contractor 

2/12-14 
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2.  D LG-2 8 COMBAT  SYSTEM 


2.1  GENERAL  SYSTEM  DESCRIPTION 

D LG-28  (USS  Wainwright)  is  one  of  30  DLG's  armed  with  the  Ter- 
rier or  Standard  Missile  (SM-1)  missile  Weapon  System.  DLG's  6 through 
15  were  recently  modernized  to  the  same  functional  capability  as  DLG's 
28  through  35,  as  were  DLG's  16  through  25.  The  latter  have  missile 
batteries  fore  and  aft  as  contrasted  to  DLG's  6 through  15  and  DLG's  26 
through  35  which  have  single  batteries.  These  ships  all  have  Naval  Tac- 
tical Data  Systems  (NTDS)  and  Terrier  Digital  Fire  Control  Systems  (DFCS) . 

The  mission  of  the  DLG  is  to  operate  independently  or  with 
strike  forces,  antisubmarine  forces,  or  hunter /killer  groups  to  provide 
area  antiair  warfare  (AAW)  defense  for  convoys  or  amphibious  assault 
forces,  and  to  coordinate  engagement  of  submarine,  air,  and  surface 
threats . 


The  major  subsystems  of  the  DLG-28  combat  system  are  the  sen- 
sor system,  the  combat  direction/weapon  direction  system,  and  the  mis- 
sile, gun,  electronic  warfare,  and  antisubmarine  warfare  Weapon  Systems. 
These  subsystems  are  integrated  into  the  total  combat  system  to  support 
tactical  operational  requirements  for  target  detection,  tracking,  iden- 
tification, evaluation,  and  assignment  to  weapons  for  controlled  engage- 
ment . 

2.1.1  Sensor  System 

The  primary  capability  for  detection,  tracking,  and  identifi- 
cation of  air  and  surface  targets  is  provided  by  the  search  radar  system 
and  its  associated  identification  friend  or  foe  (IFF)  equipments.  The 
DLG-28  is  equipped  with  a surface  search  radar  (AN/SPS-10) , a three- 
coordinate  long-range  air-search  radar  (AN/SPS-48),  and  a two-coordinate 
long-range  air-search  radar  (AN/SPS-43).  The  IFF  capability  for  the 
DLG-28  is  provided  by  the  Automatic  Identification  Mk  XII  System  (AIMS). 

Video  processing  equipment  designated  as  the  Beacon  Video 
Processor  (BVP)  operates  on  IFF  data  to  provide  an  automatic  identifi- 
cation capability  for  friendly  aircraft.  The  BVP  system  includes  a 
general-purpose  digital  computer  (CP-789/UYK)  and  associated  software. 

The  primary  capability  for  subsurface  target  detection  and 
tracking  on  the  DLG-28  is  provided  by  a sonar  detection-ranging  set  (AN/ 
SQS-26BX). 
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The  electronic  support  measures  (ESM)  functions  of  the  DLG-28 
are  provided  by  an  electronic  warfare  system  (AN/SLQ-26)  and  an  elec- 
tronic countermeasures  receiver  set  (AN/WLR-1) . 

2.1.2  Combat  Direction/Weapon  Direction  System 

Combat  direction  functions  on  the  DLG-28  are  provided  by  the 
NTDS . The  primary  elements  of  NTDS  are  a data  processing  system,  a dis- 
play system,  data  communications  equipments,  and  miscellaneous  data  con- 
version equipments.  Integrated  with  NTDS  and  sharing  common  equipments 
is  the  Weapon  Direction  System  (WDS)  Mk  11. 

The  data  processing  system  includes  three  general-purpose 
digital  computers,  associated  software,  and  various  peripheral  devices. 
The  communication  system  includes  equipments  that  provide  the  capability 
for  the  DLG-28  to  participate  in  data  exchange  over  data  Links  4A  (digi- 
tal control  data  to  aircraft),  11  (computer-to-computer  data  exchange 
with  remote  units),  and  14  (tactical  data  from  Tactical  Data  System  (TDS) 
to  non-TDS  units). 

2.1.3  Weapon  Systems 

The  primary  Weapon  System  aboard  the  DLG-28  is  the  Terrier 
guided  missile  system.  There  are  two  missile  fire  control  systems 
(Mk  76  Mod  6),  and  each  is  supported  by  a general-purpose  digital  com- 
puter (Mk  152)  and  associated  software.  Missiles  are  launched  from  a 
guided  missile  launching  system  (Mk  10  Mod  7),  which  is  shared  with  the 
antisubmarine  warfare  (ASW)  system. 

The  DLG-28  gun  Weapon  System  consists  of  a gun  fire  control 
system  (Mk  68  Mod  8),  a 5 1 1 / 54  gun  mount,  and  two  3 1 1 / 50  gun  mounts. 

ASW  functions  are  supported  by  an  underwater  battery  fire  con- 
trol system  (Mk  114  Mod  12) , ASROC  missiles  launched  from  the  Terrier 
launcher,  and  two  torpedo  tubes. 

Electronic  warfare  functions  are  supported  by  two  electronic 
countermeasures  (ECM)  sets  (AN/SLQ-22). 

2.1.4  Acquisition  History 

The  DLG-28  was  the  first  Navy  ship  with  a fully  automated  NTDS. 
The  addition  of  digital  fire  control  has  further  extended  the  digital 
capability.  The  future  incorporation  of  an  AN/SPS-48C  radar  with  Auto- 
matic Detection  and  Tracking  (ADT)  and  an  SM-2  missile  capability  will 
make  this  a highly  capable  ship. 
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NTDS  Operational  Program  (Combat  Direction  System) : The 

first  operational  NTDS  for  DLG? s were  deployed  in  1962,  and  Service 
Test  Programs,  Model  0,  were  provided  to  several  NTDS  ships.  These 
were  limited  capability  programs  designed  primarily  for  support  of 
antiair  warfare  requirements.  During  the  13  years  following  this  ini- 
tial capability,  NTDS  programs  have  undergone  extensive  modifications 
both  to  structure  and  to  operational  capabilities.  The  present  pro- 
grams are  designated  as  Model  III  programs.  The  most  capable  of  these 
is  the  Phase  3 version,  which  supports  Antiship  Missile  Defense  (ASMD) 
improvements  and  the  DFCS  on  DLG-28  class  ships.  Beginning  in  July 
1976,  Model  IV  NTDS  operational  programs  will  replace  Model  III  programs 
in  DLG-28  class  ships,  as  well  as  other  units  equipped  with  Link  11  com- 
munication equipments. 

The  13-year  period  of  development  for  DLG  NTDS  operational  pro- 
grams was  accompanied  by  a learning  process  in  the  control  and  management 
of  software  development  for  complex  real-time  tactical  data  processing 
systems.  Many  of  the  procedures  in  present  use  resulted  from  lessons 
learned  during  early  NTDS  program  development. 

After  the  initial  version  of  the  NTDS  DLG  operational  program 
was  successfully  deployed,  it  was  turned  over  to  the  Fleet  Combat  Direc- 
tion System  Support  Activity  (FCDSSA)  at  Dam  Neck  (DN) , Virginia,  for 
maintenance.  Further  modifications  are  then  supervised  by  FCDSSA  per- 
sonnel. Since  the  initial  program  was  turned  over  to  FCDSSA,  subsequent 
development  has  been  almost  entirely  under  the  auspices  of  this  activity. 
There  has  been  no  recent  program  acquisition  as  such,  but  there  is  a con- 
tinuing process  of  modification  by  an  on-site  subcontractor  under  a 
level-of -effort  contract.  This  is  also  true  for  in-process  Model  IV  de- 
velopments for  DLG-class  ships.  During  the  process  of  program  revision, 
FCDSSA  also  acts  as  integration  agent  and  validation  agent  for  the  Navy. 

DFCS  Operational  Program:  Development  of  the  DFCS  Operational 

Program  began  in  1969.  At  that  time  the  program  was  designated  as  the 
Terrier  Adaptive  Fire  Control  System  (AFCS)  computer  program.  APL/JHU 
designed  the  Advanced  Development  Model  (ADM)  version  of  this  program. 
During  early  design  phases,  the  program  was  redesignated  as  the  Digital 
Fire  Control  System  computer  program.  Vitro /Automation  Industries  was 
assigned  production  responsibility.  The  first  production  DFCS  was  eval- 
uated in  1972  aboard  the  DLG-26.  A follow-on  version  of  the  DFCS  was 
designated  as  the  Universal  DFCS  computer  program.  The  Universal  Pro- 
gram was  designed  to  operate  with  Mk  76  Mods  6,  7,  and  8 DFCS’s.  The 
DLG-28  received  DFCS  modification  in  1974. 

2.1.5  System  Diagram 

A system  block  diagram  of  the  DLG— 28  combat  system  is  shown 
in  Fig.  2-1.  Functional  changes  being  provided  by  the  introduction  of 
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the  Standard  Missile  2 (SM-2)  capability  to  DLGfs  16  through  35  are  in- 
dicated by  shaded  blocks.  The  characteristics  of  any  given  computer 
(e.g.,  Cl)  are  given  in  Table  2-1. 

2.2  COMPUTER  SYSTEM  ARCHITECTURE 

2.2.1  Computer  Characteristics 

The  DLG-28  combat  system  is  supported  by  seven  general-purpose 
stored-program  digital  computers  specifically  designed  for  use  in  real- 
time military  applications.  Computer  characteristics  and  operational 
functions  are  given  in  Table  2-1.  Any  specific  computer  can  be  cross- 
referenced  to  Fig.  2-1  by  using  the  unit  designation  (e.g.,  Cl)  in  the 
table. 


There  are  three  CP-642A/USQ-20  computers  aboard  the  DLG-28, 
and  each  communicates  directly  with  the  other  two  via  an  intercomputer 
input/output  (I/O)  channel  pair.  The  642A  has  a 32k  word  memory,  a 
word  length  of  30  bits,  and  a speed  of  8 ys. 
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TABLE  2-1 

DLG-28  COMPUTER  SUMMARY 


Unit 

Type 

Function 

Pro- 

cessor 

Memory 

SI 

CP-789/UYK  (1218) 
(18  bit,  4 ys) 

Beacon  video  processing,  auto 
detect  and  correlate,  friendly 
identification 

i 

16k 

S2 

(future) 

AN/UYK-20 

(16  bit,  750  ns) 

Automatic  Detection  and  Track- 
ing 

i 

40k 

CF 

CP-789/UYK  (1218) 
(18  bit,  4 ys) 

Control  Format  Unit:  inter- 

face control  and  data  conver- 
sion 

i 

16k 

Cl,  C2 , 

CP-64 2A/USQ-20A 

NTDS/WDS  Mk  11:  rate-aided 

3 

32k 

C3 

(30  bit,  8 ys) 

tracking 

Threat  identification  and 
evaluation,  weapon  assignment 
and  control 

Data  link  communication,  air 
intercept  control 

each 

Wl,  W2 

CP-848/UYK  (Mk  152) 
(18  bit,  2 ys) 

Missile  fire  control,  Terrier 
DFCS  Mk  76 

2 

32k 

each 

W3 

(future) 

AN/UYK-20 
(16  bit,  750  ns 

Weapon  Direction  System  Mk  14, 
weapon  assignment  and  control 

1 

64k 

m 

(future) 

AN/UYK-20 

(16  bit,  750  ns) 

Communication  Tracking  Set 
AN/SYR-1  processor,  control 
and  processing  of  SM-2  missile 
downlink  data 

1 

64k 

There  are  two  CP-789/UYK  computers  aboard  the  DLG-28.  This 
computer  is  often  referred  to  as  the  Univac  1218  Military  Computer  or 
simply  as  the  1218.  The  1218  is  a medium-scale  general-purpose  computer 
used  primarily  in  control  and  formatting  applications.  It  has  a 16k  word 
memory,  a word  length  of  18  bits,  and  a speed  of  4 ys. 

There  are  two  CP-848/UYK  computers  aboard  the  DLG-28,  and  each 
communicates  directly  with  the  other  via  an  intercomputer  I/O  channel 
pair.  This  computer  is  also  called  the  Univac  1219B  (militarized  ver- 
sion) or  more  frequently  the  Mk  152.  The  Mk  152  aboard  the  DLG-28  has 
a 32k  word  memory,  a word  length  of  18  bits,  and  a speed  of  2 ys. 
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The  general-purpose  digital  computers  aboard  the  DLG-28  are  sup- 
ported by  the  following  standard  Navy  computer  peripheral  equipment: 

1-  Mk  152  Computer  Peripheral  Equipment 

Digital  Data  Recorder  Mk  19  — Auxiliary  storage  device 
consisting  of  two  magnetic  tape  decks. 

Input/Output  Console  Mk  77  (two)  — comprised  of  a paper 
tape  perforator,  a paper  tape  reader,  a page  printer,  and 
an  alphanumeric  keyboard,  all  of  which  operate  on  a single 
computer  I/O  channel. 

2-  Other  Computer  Peripheral  Equipment 

Signal  Data  Recorder  Reproducer  RD-243/USQ-20 (V)  - mag- 
netic tape  unit  with  duplexed  I/O  for  two-computer  time- 
shared  use  (only  one  in  control  at  a time). 

Signal  Data  Recorder  Reproducer  RD-231/USQ-20 (V)  - paper 
tape  unit  with  punch/reader  capability,  used  primarily  in 
debug  operations. 

Teletypewriter  Set  AN/UGC-13  (modified)  - hard  copy  I/O 
device  used  in  operations  such  as  Link  14  data  exchange 
etc. 

2* 2* 2 Functional  Allocation  among  Computers 

The  three  CP-642A  computers  aboard  the  DLG-28  are  linked  to- 
gether to  form  the  major  data  processing  element  of  the  NTDS . This 
three-computer  complex  is  designated  as  the  NTDS  unit  computer.  The 
NTDS  unit  computer  is  supported  by  a single  computer  operational  pro- 
gram. Intercommunication  among  the  three  processors  is  accomplished 
via  intercomputer  I/O  channels.  The  DLG— 28  NTDS  complex  has  primary 
responsibility  for  the  combat  system  real-time  antiair,  antisurface, 
and  antisubmarine  combat  direction  functions,  including  tactical  data 
correlation  and  evaluation.  Also  resident  in  the  unit  computer  are  the 
program  functions  necessary  to  support  weapon  direction  requirements  for 
the  Terrier  missile  fire  control  system  and  the  gun  fire  control  system. 
This  part  of  the  system  is  designated  as  WDS  Mk  11. 

The  two  1218  (CP-789)  computers  are  required  to  support  spe- 
cial-purpose processing  in  association  with  NTDS/WDS  operations.  One 
1218  is  used  as  a part  of  the  BVP  system.  The  system  provides  the  capa- 
bility for  real-time  automatic  identification  and  tracking  of  friendly 
aircraft  through  the  processing  of  IFF  video  signals.  A direct  interface 
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from  this  computer  to  one  of  the  NTDS  CP-642A!s  is  implemented.  The 
second  1218  is  designated  as  the  Control  Format  Unit  (CFU)  computer. 

The  CFU  computer  is  used  to  provide  a single  CP-642A  computer  interface 
with  the  Mk  152  (CP-848)  computers  of  the  Terrier  missile  fire  control 
system  and  with  the  many  data  sources  connected  to  the  Keyset  Central 
Multiplexer  (KCMX) . 

Each  of  the  two  Mk  152  computers  is  a part  of  a Terrier  mis- 
sile fire  control  system.  Together  with  its  associated  software,  the 
Mk  152  is  responsible  for  the  performance  of  the  basic  computations  re- 
quired to  engage  targets  with  missiles,  according  to  a designated  op- 
erational mode.  This  includes  processing  required  for  fire  control 
radar  designation,  missile  launcher  control,  and  other  functions  that 
may  be  required  to  acquire,  track,  and  engage  targets  of  interest. 

2.2.3  Interrelation  among  Computers 

The  normal  configuration  of  computers  aboard  the  DLG-28  is 
shown  in  Fig.  2-1.  The  CP-642A  computers  (Cl,  C2,  and  C3)  communicate 
directly  with  each  other  over  intercomputer  I/O  channels.  The  Mk  152 
computers  also  communicate  directly  with  each  other  over  intercomputer 
I/O  channels.  The  1218  BVP  computer  operates  as  a peripheral  to  one  of 
the  NTDS  CP-642A  computers,  using  a peripheral  I/O  channel.  The  1218 
CFU  computer  interfaces  with  a single  CP-642A  and  a single  Mk  152,  using 
special-purpose  equipment  in  each  interface.  The  primary  function  of 
the  special-purpose  equipment  is  to  overcome  intercomputer  channel  limi- 
tations on  the  CP-642A  computers. 

The  following  combat  system  casualty  configurations  for  the 
computers  aboard  the  DLG-28  are  available: 

1.  NTDS  can  operate  at  a reduced  capability  using  only  two 
CP-642A  computers  and  a reduced  capability  operational 
program. 

2.  The  BVP  and  CFU  computers  (1218 fs)  are  interchangeable 
through  a switching  arrangement. 

3.  Either  of  the  fire  control  system  Mk  152 fs  can  interface 
with  the  NTDS/WDS  complex  via  the  CFU  computer. 

2.2.4  Functional  Interfaces  with  Sensors 

NTDS  has  the  primary  responsibility  for  the  tactical  process- 
ing of  data  derived  from  the  DLG-28  sensor  systems.  All  sensor  data 
(with  the  exception  of  certain  IFF  data)  are  input  to  the  NTDS  opera- 
tional program  via  operator  action  at  either  general-purpose  display 
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consoles  or  special-purpose  keyset  equipments.  Search  radar  data  are 
entered  via  the  display  system  complex;  electronic  support  measures 
data  and  sonar  data  are  entered  via  the  signal  conversion  equipments  of 
the  KCMX.  Automatic  (computer-to-computer)  input  of  selected  IFF  data 
is  accomplished  through  the  BVP  equipments.  Figure  2-1  shows  the  pri- 
mary computer  system/sensor  system  interfaces  for  the  DLG-28. 

2.2.5  Functional  Interfaces  with  Weapons 

NTDS/WDS  provides  the  primary  data  interface  with  all  DLG-28 
Weapon  Systems.  Communication  between  NTDS/WDS  computers  and  all  weapons 
is  accomplished  via  the  CFU  computer.  The  CFU  provides  for  direct  data 
transfer  to  one  of  the  Mk  152  computers  of  the  Terrier  missile  fire  con- 
trol systems.  This  Mk  152  computer  transfers  the  appropriate  NTDS/WDS 
data  to  the  other  Mk  152  computer.  Communication  between  the  CFU  and 
all  other  Weapon  Systems  is  accomplished  via  the  signal  conversion  equip- 
ments of  the  KCMX.  Communication  between  the  Mk  152  computers  and  asso- 
ciated fire  control  system  elements  is  accomplished  via  the  signal  con- 
version equipments  of  the  signal  data  converter  Mk  75.  Figure  2-1  shows 
the  primary  computer  system/Weapon  System  interfaces  for  the  DLG-28. 


2.3  COMPUTER  PROGRAM  ARCHITECTURE 

2.3.1  Naval  Tactical  Data  System  Computer  Program 

The  DLG-28  NTDS  computer  program  is  identified  as  a Model  III 
Phase  3 Computer  Operational  Program.  All  current  tactical  data  system 
programs  are  Model  III  programs.  The  Phase  3 version  is  the  most  capa- 
ble of  the  Model  III  programs.  For  the  DLG-28,  this  program  supports 
ASMD  improvements  and  an  intercomputer  interface  with  the  Terrier  DFCSfs. 

To  fulfill  the  various  operational  conditions  of  readiness 
that  can  exist,  two  types  of  NTDS  operational  programs  are  available  for 
use.  A Full  Operational  Capability  Program  is  designed  for  use  with  all 
three  CP-642A  computers.  Also,  there  is  a Reduced  Operational  Capabil- 
ity Program  designed  for  use  with  only  two  computers.  This  program  is 
used  in  the  event  of  a computer  system  casualty.  Both  programs  make  use 
of  the  dynamic  modular  replacement  capability  described  in  the  next  sec- 
tion. 

2.3.2  NTDS  Program  Architectural  Structure 

The  full  capability  NTDS  operational  program  is  referred  to  as 
a three-computer  dynamic  modular  replacement  (DMR)  program.  The  basic 
module  of  the  NTDS  operational  program  is  a subprogram  element  designed 
to  perform  a specific  task  or  group  of  functionally  related  tasks,  inde- 
pendently of  other  program  modules.  Each  module  is  also  designed  to 
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support  communications  with  other  modules  in  the  program  without  regard 
to  the  internal  processing  of  the  other  modules.  This  communication  is 
accomplished  under  executive  system  control  and  consists  of  either  data 
or  instruction  transfer.  During  program  development,  modules  are  speci- 
fied, designed,  programmed,  and  tested  individually. 

DMR  is  a technique  that  allows  an  NTDS  operational  program  to 
be  reconfigured  by  the  addition  or  deletion  of  certain  modules  from  the 
computer  core.  This  can  be  accomplished  during  program  execution  with- 
out disruption  to  normal  tactical  operations.  DMR  helps  overcome  pres- 
ent core  constraints  on  the  size  of  the  operational  program  while  pro- 
viding the  capability  for  satisfying  several  diverse  mission  requirements 
with  a single  computer  program.  Modules  that  are  entered  into  fixed  core 
locations  at  program  loading  are  referred  to  as  resident  modules.  Mod- 
ules that  can  be  dynamically  added  or  deleted  from  the  program  during 
execution  are  referred  to  as  transient  modules.  In  the  DLG-28  opera- 
tional program,  transient  modules  are  entered  into  core  from  a magnetic 
tape  unit. 


The  basic  structure  of  all  NTDS  modules,  resident  and  tran- 
sient, includes  a data  section  and  an  instruction  section.  The  data  sec- 
tion includes  local  data  for  module  use  only,  executive  interface  data 
to  be  used  in  the  transfer  of  Central  Processing  Unit  (CPU)  control,  and 
a storage  area  for  messages  received  from  other  modules.  The  instruc- 
tion section  includes  a real-time  instruction  set  and,  if  appropriate, 
may  also  include  a periodic  instruction  set  and/or  an  equipment  inter- 
face instruction  set.  The  executive  system  controls  entry  into  a module’s 
real-time,  periodic,  or  equipment  processors.  Each  module  has  a unique 
priority  designator  that  indicates  when  CPU  control  will  be  transferred 
to  its  specific  processing  tasks.  This  designator  is  a part  of  the  ex- 
ecutive interface  data  contained  in  the  module’s  data  section. 

2.3.3  NTDS  Executive  Program 

The  NTDS  executive  system  is  constructed  in  four  functional 
sections.  These  sections  are  designated  as  Common  Control  (CC) , Execu- 
tive (EX),  Intermodule/Intercomputer  (IMIC) , and  Data  Update  (DU).  An 
identical  executive  system  resides  in  each  of  the  three  CP-642A  com- 
puters used  by  the  operational  program,  and  processing  in  all  three  com- 
puters proceeds  independently  and  simultaneously.  Control  is  trans- 
ferred to  the  executive  system  of  each  computer  after  the  program  has 
been  loaded  and  brought  on  line. 

The  executive  system  Common  Control  section  contains  a common 
data  area  and  an  area  for  common  processing  routines.  These  items  can 
be  referenced  by  any  module,  as  required.  The  common  data  area  contains 
fixed  length  tables  for  storing  track  data,  console  data,  and  data  ex- 
traction information.  The  common  routines  area  contains  mathematical 
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routines  such  as  sine,  cosine,  and  square  root.  It  also  contains  other 
routines  such  as  those  required  for  message  data  packing  and  preset  op- 
erations. 


The  Executive  section  is  responsible  for  maintaining  program 
control  over  all  modules  resident  within  its  computer.  It  schedules 
all  real-time  and  periodic  references  to  each  of  these  modules.  Task 
scheduling  is  accomplished  according  to  a predefined  priority  scheme 
that  is  based  on  both  the  module’s  servicing  priority  and  whether  the 
required  module  task  is  a real-time  task  or  a periodic  task.  The  Execu- 
tive section  is  made  up  of  three  segments:  a display  initiation  sub- 
executive, a real-time  subexecutive,  and  a periodic  subexecutive.  The 
highest  program  priority  is  given  to  display  initiation  tasks.  These 
are  followed  by  real-time  tasks  and  then  by  periodic  tasks.  Tasks  are 
serviced  in  priority  order  for  each  Executive  section  cycle,  so  that 
real-time  tasks  are  not  serviced  if  there  are  any  display  initiation 
tasks  to  be  completed,  and  periodic  tasks  are  not  serviced  if  there  are 
any  real-time  tasks  to  be  completed.  Display  initiation  tasks  are 
executed  only  in  the  computer  interfacing  with  the  display  system  com- 
plex. 


The  primary  function  of  the  Executive  system's  IMIC  section  is 
to  control  message  transfer  between  modules.  The  IMIC  section  also  con- 
trols computer  preset  procedures  and  provides  for  common  data  update  via 
the  Data  Update  section  of  the  executive  system.  Intermodule  message 
transfer,  whether  between  modules  of  the  same  computer  or  between  modules 
of  different  computers,  can  only  be  accomplished  through  the  IMIC  section 
of  the  Executive  system. 

The  Executive  system's  Data  Update  section  is  responsible  for 
entering,  updating,  and  clearing  data  in  the  data  stores  area  of  the 
Common  Control  section.  Messages  are  transferred  to  the  Data  Update  sec- 
tion via  the  IMIC  section.  Messages  from  any  module  that  are  addressed 
to  the  Data  Update  section  are  sent  to  the  Data  Update  sections  of  all 
three  of  the  system's  computers.  The  structure  of  the  Data  Update  sec- 
tion of  the  Executive  system  is  similar  to  that  of  the  basic  program 
module,  and,  in  the  program,  Data  Update  is  given  the  highest  priority 
for  real-time  processing.  This  ensures  that  program  common  stores  are 
always  updated  at  the  first  available  opportunity. 

2.3.4  NTDS  Equipment  Interfaces 

The  NTDS  computer  program  communicates  with  the  following  on- 
line equipment  via  the  CP-642A  peripheral  I/O  channels: 

a.  Recorder  Reproducer  RD-243/USQ-20(V)  (magnetic  tape  unit) 

b.  Recorder  Reproducer  RD-231/USQ-20 (V)  (paper  tape  unit) 
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c.  Teletypewriter  Set  AN/UGC-13  (computer  operations) 

d.  Teletypewriter  Set  AN/UGC-13  (Link  14  operations) 

e.  Data  Display  Group  AN/SYA-4  (consoles  and  associated  equip- 
ments) 

f.  BVP  Computer  (IFF  video  processing) 

g.  CFU  Computer  (digital  data  formatting  etc.) 

h.  Video  Signal  Simulator  SM-319A/SYA-4  (test  functions) 

i.  Weapon  Control  Panel  SB— 1881/USQ— 20  (special  purpose  con- 
sole) 

j • Data  Terminal  Set  OA-4477/SSQ-29  (Link  11  operations) 

k.  Digital  Data  Communications  Control  Set  AN/SSW-1A  (Link  4A) 

Communication  between  the  NTDS  computers  and  these  equipments 
is  accomplished  under  program  control  using  the  I/O  instructions  in  the 
computer  repertoire. 

The  primary  tactical  data  interfaces  supported  by  the  computer 
program  are  with  the  display  equipments,  the  CFU  computer,  the  BVP  com- 
puter, and  the  data  link  equipments  (Links  11,  14,  and  4A)  . These  are 
shown  in  Fig.  2-1.  The  most  demanding  interface  is  that  with  the  dis- 
play complex.  The  NTDS  program  provides  for  generation  and  refresh  of 
symbol  display  data  at  a rate  sufficient  to  prevent  ’’flickering"  (ap- 
proximately 16  times/s). 

2.3.5  NTDS  Module  Functions 

The  modules  of  the  NTDS  operational  program,  a brief  descrip- 
tion of  their  primary  functions,  and  their  approximate  core  allocations 
are  given  in  Table  2-2. 

The  percentage  of  computer  time  required  by  each  module  in  the 
execution  of  its  tasks  is  a function  of  which  modules  are  in  the  system 
and  the  complexity  of  the  tactical  environment.  The  Executive  system 
limits  module  real-time  processing  tasks  to  a maximum  of  10  ms  and  an 
average  of  5 ms.  Module  periodic  tasks  are  limited  to  a maximum  of  35  ms 
and  an  average  of  20  ms. 

2.3.6  Digital  Fire  Control  System  Computer  Program 

The  computer  operational  program  used  in  the  Mk  152  computer 
of  the  Terrier  Mk  76  Missile  Fire  Control  System  is  designated  as  the 
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TABLE  2-2 

DLG-28  NTDS  MODULE  DESCRIPTIONS 


Module  Name 

Primary  Function 

Core  Allocation 

Ant i submarine 

Coordination  of  shipboard  antisubmarine  warfare  activities. 
Processes  data  received  from  underwater  battery  fire  con- 
trol system.  Supports  antisubmarine  warfare  coordinator 
console  mode. 

3850 

Basic  Training 

Simulation  of  a realistic  tactical  environment  for  train- 
ing purposes.  Includes  simulation  of  radar  returns  for 
display  on  consoles. 

3150 

Beacon  Video  Processor 

Provides  interface  between  NTDS  program  and  BVP  equipment. 
Supports  BVP  tracker  console  mode. 

4800 

Combat  Systems 
Operability  Test 

Processes  and  prints  out  selected  data  extraction  events. 

2900 

Control  Format 
Interface 

Provides  interface  between  NTDS  program  and  both  the  KCMX 
and  the  missile  fire  control  computers. 

900 

Data  Update 
(CCEXIMDU) 

Includes  Executive,  Intermodule/Intercomputer,  Data  Update, 
and  Common  Control  data  sections.  Functions  as  NTDS  execu- 
tive system. 

3900 

Data  Extraction 

Controls  the  extraction  and  recording  on  magnetic  tape  of 
system  operational  data. 

1300 

Display 

Provides  interface  between  console  operators  and  the  NTDS 
program  via  the  display  subsystem.  Supports  all  console 
displays  and  pushbutton  operations. 

11350 

Dynamic  Modular 
Replacement 

Master  provides  for  modification  of  program  configuration. 
Slave  supports  bookkeeping  functions  in  non-master  com- 
puters . 

3050 

100 

Electronic  Warfare 

Provides  interface  between  NTDS  program  and  Electronic  War- 
fare (EW)  data  entry  devices.  Supports  an  EWT  console  mode. 

11900 

Threat  Evaluation 

Provides  estimate  of  relative  threat  for  all  system  tracks. 

1750 
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TABLE  2-2  (cont'd) 


Module  Name 

Primary  Function 

Core  Allocation 

Tracking 

Performs  tasks  associated  with  rate-aided  tracking  based  on 
track  position  data  entries.  Supports  detector/tracker  and 
track  supervisor  console  modes. 

9900 

Weapon  Assignment 

Provides  solutions  to  force  and  ownship  tactical  problems 
and  provides  processing  for  engagement  orders.  Supports 
ship  weapon  coordinator's  console  mode. 

10100 

Weapon  Control 

Controls  the  exchange  of  order  and  status  information  between 
NTDS  and  the  missile  and  gun  systems.  Supports  the  fire  con- 
trol system  coordinator  and  engagement  controller  console 
modes . 

7100 

Height 

Processes  height  inputs  and  a limited  number  of  size  inputs 
from  consoles. 

600 

Height /Size 

Processes  air-track  height  and  size  data  inputs  from  consoles. 

1650 

Identification 

Processes  track  identification  data  received  from  consoles 
and  from  other  modules  such  as  the  BVP.  Supports  the  identi- 
fication console  mode. 

1950 

Intercept  Control 

Supports  intercept  controller  tasks  for  vectoring  intercep- 
tors to  attack  positions.  Calculates  trial  intercepts. 

5300 

Intercept  Vector 

Supports  intercept  controller  tasks  for  vectoring  intercep- 
tors to  attack  positions.  Calculates  pursuit  or  collision 
geometries . 

2900 

Link  4 A 

Provides  an  interface  between  the  NTDS  program  and  the  Link  4A 
communications  equipments. 

950 

Link  14 

Selects  and  formats  NTDS  tactical  data  and  supplies  it  for 
broadcast  to  non-NTDS  ships  in  the  force. 

2450 

Resident  Control 

Provides  utility  processing  routines  such  as  inspect,  change, 
clear,  etc. 

1850 

Surface  Operations 

Provides  solutions  to  trial  maneuver  problems  for  closest  point 
of  approach.  Maintains  position  and  velocity  for  ownship. 

2350 

System  Tracker/Link  11 

Provides  processing  for  Link  11  data  exchange  with  other  units. 

6950 
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Universal  Fire  Control  Computer  Program.  It  operates  with  the  Mk  76 
Mod  7 and  Mod  8 Terrier  fire  control  systems,  as  well  as  the  DLG-28 
Mk  76  Mod  6 system.  There  is  an  identical  DFCS  computer  program  resi- 
dent in  the  Mk  152  computer  of  each  missile  fire  control  system.  Commu- 
nication between  the  two  computer  programs  is  accomplished  over  Mk  152 
intercomputer  I/O  channels. 

2.3.7  DFCS  Program  Architectural  Structure 

The  DFCS  computer  program  is  a modular  program.  Modular  ele- 
ments are  designated  as  subprograms.  The  Universal  Fire  Control  Computer 
Program  consists  of  34  subprograms,  identified  as  either  Executive  and 
Control  subprograms  (11)  or  Data  Processing  subprograms  (23). 

A subprogram  is  designed  to  accomplish  a specific  task  or  a 
set  of  functionally  related  tasks.  A task  is  an  operation  (or  group  of 
operations)  that  is  functionally  independent  of  other  program  operations. 
An  example  of  a task  is  ’’Perform  Trigonometric  Conversion.”  This  is  a 
task  of  the  Common  Processing  subprogram.  The  functions  of  a subprogram 
are  defined  by  the  tasks  to  be  performed  by  that  subprogram.  A task  may 
be  further  defined  by  the  individual  functions  that  are  associated  with 
its  processing.  Each  subprogram  having  independent  tasks  to  perform  is 
designed  with  its  own  executive  subroutine  to  sequence  to  its  tasks,  as 
appropriate.  The  overall  program  is  then  controlled  by  an  executive  sub- 
program that  contains  higher  level  control  and  timing  logic. 

Of  the  34  DFCS  subprograms,  about  17  are  used  in  the  process- 
ing of  tactical  operations.  The  remaining  subprograms  are  used  pri- 
marily in  data  extraction  or  system  test  operations. 

2.3.8  DFCS  Executive  Program  Functions 

The  DFCS  computer  program  is  designed  such  that  tactical  sub- 
programs are  selected  and  executed  according  to  specific  predefined 
modes  of  Fire  Control  System  (FCS)  operation.  There  are  nine  primary 
operational  modes  defined;  eight  are  designated  as  tactical  modes,  and 
one  is  designated  as  the  System  Test  Mode.  Tactical  mode  processing  re- 
quires the  use  of  17  subprograms  including  the  Executive  and  FCS  Control 
subprograms . 

The  eight  tactical  modes  and  their  primary  functions  are  as 

follows : 


1.  Air  Ready  — provides  for  the  setup  of  an  FCS  standby  con- 
dition, wherein  all  elements  are  in  a stowed  position  but 
are  ready  for  immediate  response. 
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2.  Designation  — provides  for  initial  positioning  of  the  radar 
beam  to  a point  in  space  corresponding  to  the  designation, 
provides  for  automatic  selection  and  execution  of  the 
proper  director  search  pattern,  and  provides  for  response 
to  input  control  and  status  signals  while  the  director  is 
attempting  to  acquire  the  target. 

3.  Air  — executes  processing  functions  for  normal  operations 
in  an  air  mode  including  director  control,  target  position 
prediction,  launch  missile  orders,  engageability  calcula- 
tions, etc. 

4.  Shore  executes  functions  that  are  required  in  the  mis- 
sile engagement  of  shore  targets. 

5.  Surface  One  Director  — executes  functions  appropriate  to 
the  engagement  of  surface  targets  with  a beam-riding  mis- 
sile. 

6.  Surface  Homing  — executes  functions  that  are  required  in 
the  engagement  of  surface  targets  with  missiles  in  the 
surface  homing  mode. 

7.  Self-Defense  CBT  — executes  functions  appropriate  to  en- 
gagements using  the  continuous  boat  track  (CBT)  capability. 

8.  Self-Defense  SSE  — executes  functions  appropriate  to  en- 
gagements using  the  sector  scan  engagement  (SSE)  capabil- 
ity. 

Subprogram  sequencing  and  execution  for  these  tactical  opera- 
tional modes  is  controlled  by  the  FCS  Control  subprogram.  This  subpro- 
gram is  in  turn  under  the  control  of  the  DFCS  Executive  subprogram. 

These  two  subprograms  perform  the  tactical  processing  executive  func- 
tions . 


The  major  tasks  of  the  Executive  subprogram  include  defining 
when  the  FCS  Control  subprogram  is  to  be  executed,  initiating  and  con- 
trolling the  clock  cycle  time,  and  maintaining  time  correlation  with  the 
NTDS  computer  system.  The  FCS  Control  subprogram  has  only  one  task  — to 
control  when  the  subprograms  for  which  it  is  responsible  are  to  be  exe- 
cuted. On  the  basis  of  system  status  signals,  a mode  determination  sub- 
program establishes  the  correct  mode  to  be  executed.  The  FCS  Control 
subprogram  then  calls  the  required  subprograms  for  that  mode. 

The  basic  execution  rate  of  the  FCS  Control  subprogram  is  con- 
trolled by  a rigidly  defined  Executive  subroutine.  The  execution  rate 
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for  subprograms  in  the  Designation  and  SSE  modes  is  32  times/s.  The 
execution  rate  for  all  other  subprograms  is  16  times/s,  except  for  the 
Engage  subprogram  which  is  2 times/s.  All  of  these  execution  rates  are 
derived  from  a basic  32-per-second  rate  through  a counting  process  in 
the  FCS  Control  subprogram.  A brief  description  of  the  subprogram  ele- 
ments is  given  in  Section  2.3.10. 

This  section  has  described  executive  processing  for  tactical 
mode  operations.  A similar  processing  routine  is  used  for  system  mainte- 
nance test  (SMT)  operations.  These  are  accomplished  under  control  of  the 
SMT  Control  subprogram  in  conjunction  with  the  Executive  subprogram. 

2.3.9  DFCS  Equipment  Interfaces 

The  DFCS  computer  program  communicates  with  the  following  on- 
line equipments: 

1*  Signal  Data  Converter  Mk  75 

2«  Digital  Data  Transfer  Unit  (DDTU)  (part  of  Signal  Data 
Converter) 

3.  Digital  Computer  Mk  152  (other  FCS) 

4.  Digital  Data  Recorder  Mk  19  (magnetic  tape  unit) 

5.  Input/Output  Console  Mk  77  (PTU,  printer,  keyboard) 

6.  Control  Panel  Mk  298  (switching  etc.) 

7.  RF  Simulator  System 

Communication  between  the  DFCS  computer  and  these  equipments 
is  accomplished  under  program  control  using  the  input/output  instruc- 
tions in  the  computer  repertoire. 

The  primary  tactical  operational  data  interfaces,  as  shown  on 
Fig.  2-1,  are  the  NTDS/WDS  interface  and  the  fire  control  radar  ard 
launcher  interfaces.  The  DFCS  computer  program  operates  on  inputs  re- 
ceived from  NTDS/WDS  via  the  CFU  and  from  the  fire  control  radar  and 
missile  launching  system  via  the  Signal  Data  Converter.  After  the  ap- 
propriate processing  is  accomplished  in  response  to  these  inputs,  the 
DFCS  program  generates  outputs  of  designation  position  and  search  and 
surveillance  patterns.  When  appropriate,  the  program  also  solves  the 
fire  control  problem  to  derive  outputs  of  launcher  position  and  rate 
orders,  missile  orders,  target  angular  rates,  target  present  position, 
and  engageability  parameters.  Engageability  and  DFCS  status  are  pro- 
vided to  NTDS/WDS  for  use  in  combat  direction/weapon  direction  opera- 
tions. The  DFCS  interface  with  NTDS/WDS  is  accomplished  through  a 
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single  DFCS  computer.  That  computer  forwards  NTDS/WDS  information  to 
the  other  DFCS  computer  over  a direct  intercomputer  interface. 

2.3.10  DFCS  Subprogram  Functions 

The  DFCS  computer  program  is  divided  into  an  Executive  subpro- 
gram, 2 mode  control  subprograms,  8 test  control  subprograms,  22  data 
processing  subprograms,  and  a common  processing  subroutines  subprogram. 
The  subprograms  of  the  DFCS  operational  program,  a brief  description  of 
their  primary  functions,  and  their  approximate  core  allocations  are  given 
in  Table  2-3. 


TABLE  2-3 

DLG-28  DFCS  SUBPROGRAM  DESCRIPTIONS 


Subprogram  Name 

Primary  Function 

Core 

Allocation 

Air  Ready 

Provides  for  positioning  director  to  stow  position,  generat- 
ing launcher  stow  orders,  etc. 

200 

ASMD  Readiness 

Supports  a system  maintenance  test. 

900 

Automatic  Monitoring 

Provides  display  interface  for  use  in  system  monitoring. 

870 

CFU  Interface 

Provides  for  program  interface  with  CFU  computer. 

1250 

Common  Processing 

Provides  a collection  of  mathematical  equations  and  logical 
processes  designed  to  solve  recurring  program  operations. 

1130 

Data  Extraction 

Provides  magnetic  tape  storage  for  selected  quantities. 

1460 

Designat ion /Search 

Performs  major  program  functions  for  all  designation  or 
search  modes. 

2800 

DFCS  UFCCP  Executive 

Provides  overall  system  executive  functions.  Establishes 
when  FCS  Control  subprogram  is  executed,  determines  when 
each  program  clock  cycle  is  initiated  and  controls  dura- 
tion, and  provides  for  time  correlation  with  NTDS . 

30 

Engageability  and 
Display 

Combines  computation  of  target  engageability  and  a mis- 
cellany of  display  functions  that  require  low  update  rates. 

610 

FCS  Control 

Controls  the  execution  of  17  subprograms  (primarily  tacti- 
cal subprograms) . 

220 

Fire  Control 
Parameters 

Supports  a system  maintenance  test. 

2260 

Firing  and  Casualty 
Readiness 

Supports  a system  maintenance  test. 

1050 

Interbattery 

Not  applicable  to  DLG-28 

430 

Intercomputer 

Provides  for  data  transfer  between  two  Mk  152' s. 

430 

IOC  Display 

Provides  program  output  interface  with  I/O  console. 

410 

Launch er /Missile 
Orders 

Computes  launch  doctrine  and  orders  for  the  launcher  and 
missile 

1380 

Mode  Determination 

Provides  for  evaluation  of  major  computer  mode-determining 
logic  and  makes  results  available  for  internal  and  external 
use. 

830 

Relative  Alignment 

Supports  a system  maintenance  test. 

4950 
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TABLE  2-3  (cont'd) 


Subprogram  Name 

Primary  Function 

Core 

Allocation 

RF  Simulator  Control 

Supports  a system  maintenance  test. 

1140 

SDC  Input 

Formats  data  from  Signal  Data  Converter  for  use  by 
program. 

590 

SDC  Output 

Provides  program  output  interface  with  Signal  Data  Converter 

400 

Secondary  Air  Search 

Supports  a system  maintenance  test. 

1240 

Shore 

Computes  functions  associated  with  shore  mode. 

230 

SMT  Control 

Controls  the  execution  of  11  subprograms  (primarily  SMT 
subprograms) . 

350 

SMT  Input  Processing 

Interprets  and  converts  data  from  I/O  console  for  use  by 
program. 

1390 

Surface  One-Director 

Computes  functions  associated  with  surface  mode. 

40 

Surface/Shore  Mode 
Readiness 

Supports  a system  maintenance  test. 

2300 

Target  Generation 

Supports  a system  maintenance  test. 

680 

Target  Position 
and  Prediction 

Calculates  target  position  quantities  and  predicts  certain 
future  target  positions. 

600 

Tracking 

Provides  for  control  of  director  angular  position  in  all 
modes  for  which  one  or  both  axes  are  to  be  positioned  on 
the  basis  of  55B  derived  target  data. 

1190 

True  Alignment  and 
Transmission 

Supports  a system  maintenance  test. 

2300 

UD1230  Input 
Processing 

Not  applicable  to  DLG-28. 

490 

UD1230  Output 
Processing 

Not  applicable  to  DLG-28. 

550 

Weapon  System 
Parameters 

Supports  a system  maintenance  test. 

2060 
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2.4  SOFTWARE  DEFINITION,  DESIGN,  AND  IMPLEMENTATION 

2.4.1  NTDS  Program  Definition,  Design,  and  Implementation 

The  NTDS  computer  operational  program  for  the  DLG-28  is  an  in- 
service  program  that  has  evolved  through  a series  of  design  improvements. 
Most  of  the  definition,  design,  and  implementation  activities  associated 
with  this  program  development  have  been  related  to  the  modification  of 
an  existing  program.  The  selected  modular  structure  of  the  program  al- 
lows modification  of  specific  functional  areas  with  minimum  impact  on 
other  functional  areas.  This  is  a necessary  and  desirable  feature  since 
the  NTDS  program  must  be  frequently  modified  to  accommodate  new  require- 
ments that  result  from  the  implementation  of  new  equipment  or  revised 
operating  concepts. 


The  definition  phase  for  program  modification  is  normally  un- 
dertaken as  a joint  effort  between  the  maintenance  agent  (FCDSSA(DN) ) and 
an  agent  for  the  activity  sponsoring  the  modification.  The  requirements 
associated  with  the  modification  are  documented  in  appropriate  system- 
level  specifications.  Where  the  modification  results  in  new  require- 
ments for  an  interface  with  the  NTDS  computer,  a jointly  developed  and 
jointly  promulgated  Interface  Design  Specification  is  issued.  Continu- 
ity of  program  design,  as  well  as  technical  and  operational  feasibility, 
is  assured  by  the  participation  of  the  maintenance  agent  in  the  require- 
ments definition  phases  of  program  modification. 

To  support  effective  implementation  of  new  design  requirements, 
FCDSSA(DN)  has  prepared  a comprehensive  Program  Production  Procedures 
Manual  (PPPM) . This  four-volume  document  provides  guidance  in  all  phases 
of  program  production  through  delivery  and  maintenance. 


Program  modifications  coded  in  machine  language  for  the  CP— 
642A  are  produced  via  the  CS-1  compiling  system,  an  early  version  of  one 
of  the  Navy's  current  standard  compilers  (CMS-2).  Where  low-level  lan- 
guage code  is  more  appropriate  to  implementation  requirements,  its  use 
is  allowed  (e.g.,  executive  programs,  input /output , etc.). 

2.4.2  DFCS  Program  Definition,  Design,  and  Implementation 

The  definition  phase  of  the  DFCS  design  effort  established  com- 
puter program  performance  requirements  for  the  DFCS.  These  requirements 
were  developed  to  support  a specified  level  of  operational  capability  for 
the  missile  Weapon  System.  The  requirements  definition  task  included  an 
analysis  of  known  limitations  and  deficiencies  in  existing  analog  sys- 
tems. 

An  ADM  of  the  DFCS  was  developed  by  the  Applied  Physics  Labo- 
ratory. The  ADM  performed  the  tactical  functions  associated  with  the 
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operations  of  the  fire  control  system  and  demonstrated  the  improvement 
in  tactical  performance  that  could  be  achieved  through  implementation  of 
a DFCS . 


As  a result  of  the  success  of  the  ADM,  the  Naval  Ordnance  Sys- 
tems Command  (NAVORD)  tasked  the  Applied  Physics  Laboratory  and  Automa- 
tion Industries/Vitro  Laboratories  to  develop  a production  version  of 
the  DFCS.  Using  the  ADM  as  a baseline,  APL  defined  Performance  and  Capa- 
bility Requirements  (XWS  13058)  for  the  DFCS.  The  production  version  of 
the  DFCS  program  was  designed  and  coded  by  Vitro  and  documented  in  Weapon 
Specification  XWS  9500.  This  effort  included  the  design  and  implementa- 
tion of  maintenance  test  programs  and  a data  extraction  capability.  Docu- 
mentation for  the  DFCS  computer  program  was  prepared  in  accordance  with 
the  guidelines  of  NAVORD  XWS  8506,  Requirements  for  Digital  Computer  Pro- 
gram Documentation. 

The  DFCS  program  was  developed  using  a top-down  design  philoso- 
phy. The  program  was  easily  organized  into  independent  functional  areas. 
Functional  diagrams  and  flowcharts  were  prepared  as  a part  of  the  design 
documentation.  The  TRIM  III  assembly  language  was  used  for  the  program. 

The  success  of  the  design  and  implementation  effort  can  be  at- 
tributed in  part  to  the  extensive  interaction  between  those  responsible 
for  defining  program  performance  requirements  and  those  responsible  for 
program  design  implementation.  This  interaction  is  addressed  in  more  de- 
tail in  Section  2.5.2. 


2.5  SOFTWARE  VALIDATION  AND  INTEGRATION 

2.5.1  NTDS  Program  Validation  and  Integration 

The  validation  and  integration  of  NTDS  program  modifications  is 
the  responsibility  of  the  NTDS  life-cycle  maintenance  agent,  FCDSSA(DN) . 
FCDSSA(DN)  has  developed  a considerable  capability  for  test  and  accep- 
tance of  NTDS  computer  programs.  This  capability  includes  a test  de- 
partment whose  function  is  to  plan,  control,  and  execute  thorough  testing 
of  NTDS  computer  programs.  Extensive  use  is  made  of  on-site  equipments, 
including  a DLG-28  Combat  Direction  System  mock-up.  The  DLG-28  mock-up 
with  appropriate  simulation  support  provides  the  capability  to  test  pro- 
gram designs  in  an  operational  environment. 

Test  activities  have  been  allocated  to  four  major  test  areas: 
program  module  tests,  computer  integration  tests,  computer  system  tests, 
and  operational  program  functional  checkouts.  To  ensure  that  perfor- 
mance requirements  are  supported  by  program  design,  FCDSSA  participates 
in  the  preparation  of  test  plans,  test  specifications,  and  test  proce- 
dures. Details  of  test  management  procedures  are  provided  in  Volume  IV 
of  the  PPPM. 
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Performance  deficiencies  detected  in  either  the  development  or 
maintenance  phases  of  a program  are  documented  in  standardized  Trouble 
Reports,  These  can  originate  from  three  sources:  developing  agency, 

procuring  agency,  or  the  Fleet.  Trouble  reports  are  coded  according  to 
severity  and  are  forwarded  to  the  appropriate  activities  for  action. 
Procedures  for  Trouble  Report  preparation  are  included  in  the  PPPM. 

2.5.2  DFCS  Program  Validation  and  Integration 

System  test  and  integration  activities  for  the  DFCS  program 
were  the  responsibility  of  the  Applied  Physics  Laboratory.  Since  APL 
was  also  responsible  for  the  definition  of  DFCS  program  performance  re- 
quirements, a system  of  checks  and  balances  for  the  definition,  design, 
and  validation  phases  of  program  development  was  achieved.  Program  de- 
sign activities  supported  by  Vitro  provided  information  that  assisted 
in  completing  performance  requirements  specifications  and  in  assuring 
that  performance  requirements  were  consistent  and  valid.  These  perfor- 
mance requirements  in  turn  provided  the  standard  by  which  program  de- 
sign was  measured.  Detailed  certification  test  plans  and  procedures 
were  developed  for  use  in  testing  phases  of  the  DFCS  program  develop- 
ment. Initial  testing  was  accomplished  at  the  subprogram  or  module 
level.  This  was  followed  by  system-level  testing  at  several  test  site 
facilities.  These  facilities  were  located  at  APL,  Naval  Surface  Weapons 
Center  (NSWC)  Dahlgren,  and  the  Guided  Missile  School  (GMS)  at  Dam  Neck. 

The  APL  Land-Based  Test  Site  (LBTS)  consisted  of  a Mk  152 
digital  fire  control  computer,  SPG-55B  radar  set,  Mk  75  Signal  Data 
Converter,  UYA-4  PPI  display  console,  and  a Univac  1218  (CP-789)  com- 
puter. The  1218  had  a target  generator  and  provided  simulated  inputs 
to  the  DFCS  computer.  Live  radar  inputs  were  also  available.  The  1218 
generated  displays  for  a UYA-4  console  that  was  used  as  a test  input 
and  monitor  console.  The  1218  performed  data  extraction  to  a magnetic 
tape  unit.  The  test  procedures  would  typically  require  the  operator  to 
set  up  specific  inputs  and  look  for  specific  outputs  either  on  his  con- 
sole or  in  the  extracted  data. 

The  NSWC  Dahlgren  facility  had  a wraparound  tester  that  also 
used  a second  computer  and  a UYA-4  to  generate  test  targets  and  monitor 
outputs.  No  live  radar  data  were  available.  Testing  at  NSWC  could  be 
performed  manually  as  at  APL,  or  automatically.  In  the  automatic  tests, 
a stimulus  magnetic  tape  was  generated  off-line.  The  Mk  152  program 
was  modified  to  read  this  tape  and  record  the  results  of  the  DFCS  pro- 
cessing. The  answers  were  then  compared  with  answers  that  had  been 
computed  off-line.  This  was  found  to  be  a useful  testing  procedure. 

The  final  step  in  system  testing  was  to  verify  system  opera- 
tion at  GMS  Dam  Neck  by  placing  the  DFCS  in  an  operating  combat  system 
configuration.  This  included  interfacing  the  DFCS  to  an  NTDS/WDS  com- 
bat direction  system  and  a fire  control  radar  set. 
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Each  of  the  testing  techniques  was  found  to  be  useful  in  DFCS 
program  validation.  In  general,  the  testing  and  integration  tasks  pro- 
ceeded smoothly  with  no  serious  problems  or  delays. 

Integration  activities  for  the  DFCS  were  placed  under  tight 
control  through  the  establishment  of  a Digital  Steering  Committee  (DSC) . 
This  committee  was  chaired  by  Naval  Ship  Weapons  Systems  Engineering 
Station  (NSWSES)  and  included  representatives  from  NAVORD,  APL,  Vitro, 
NSWC  Dahlgren,  FCDSSA(DN),  and  Fleet  Missile  Systems  Assessment  and 
Evaluation  Group  (FMSAEG) . The  activities  of  this  committee  encompassed 
all  phases  of  program  development.  The  DSC  proved  to  be  a valuable 
asset  to  the  DFCS  program  development  effort.  Major  contributions  of 
the  DSC  were  in  the  general  coordination  and  management  of  integration 
tasks,  the  resolution  of  design  conflicts,  and  the  review  and  verifica- 
tion of  specifications  and  other  documentation. 


2.6  SOFTWARE  ACQUISITION  MANAGEMENT  ORGANIZATION  AND  METHODS 

2.6.1  NTDS  Acquisition  Management 

The  organizations  involved  in  software  acquisition  for  the 
DLG-28  NTDS  Computer  Operational  Program  are  listed  in  Table  2-4. 


TABLE  2-4 

DLG-28  NTDS  ACQUISITION  MANAGEMENT 


Program  Manager 

FCDSSA(DN) 

System  Contractor 

FCDSSA(DN) 

Software  Contractor 

ISSI 

Type  Contract 

Level  of  Effort 

Program  Status 

Deployed 

Maintenance  Agent 

FCDSSA(DN) 

Software  Deliverables 

Operational  Program  and 
Program  Documentation 

Validation  Agent 

FCDSSA(DN) 

Integration  Agent 

FCDSSA(DN) 
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As  is  apparent  from  this  list,  FCDSSA(DN)  has  primary  respon- 
sibility for  the  DLG-28  NTDS  software.  This  responsibility  includes  ac- 
quisition  management  as  appropriate  to  implementation  of  program  modifi- 
cations. Both  the  management  organization  and  acquisition  methods  are 
well  established  and  are  described  in  detail  in  Volume  I of  the  PPPM. 

The  NTDS  operational  program  for  the  DLG— 28  has  undergone  sev- 
eral major  modifications  since  it  was  turned  over  to  FCDSSA  for  life- 
cycle  maintenance.  The  present  program  is  designated  as  a Model  III 
Phase  3 Program.  A change  in  Model  number  accompanies  a change  in  digi- 
tal data  link  requirements  for  tactical  data  system  programs.  A change 
in  phase  number  results  from  modifications  to  a model  which  incorporate 
new  operational  capabilities.  The  Model  III  Phase  3 program  is  the 
most  capable  of  currently  implemented  DLG  programs.  A Model  IV  Com- 
puter Operational  Program  is  presently  being  developed  for  the  DLG-28 
class  ship. 

Acquisition  management  factors  that  have  been  found  beneficial 
to  software  development  include  an  early  data  base  design  freeze  and  the 
use  of  an  on-site  contractor  working  under  a level-of-ef fort  contract. 
FCDSSA(DN)  maintains  a day-to-day  working  relationship  with  its  contrac- 
tors. Both  Navy  and  contract  personnel  are  experienced  and  knowledge- 
able in  DLG  combat  system  operational  requirements,  and  this  capability 
is  a definite  asset  to  the  implementation  of  program  modifications.  In 
general,  problems  are  more  easily  identified,  and  required  actions  are 
taken  earlier  than  would  be  possible  under  other  types  of  contractor 
support . 


2.6.2  DFCS  Acquisition  Management 

The  various  organizations  involved  in  the  DFCS  software  acqui- 
sition are  listed  in  Table  2-5. 

DFCS  acquisition  management  was  a primary  responsibility  of 
the  DFCS  DSC.  The  DSC  exercised  control  over  program  configuration,  de- 
velopment, test,  and  integration.  The  DSC  was  involved  in  the  review 
cycle  for  all  program  documentation.  Acquisition  procedures  followed 
an  orderly  software  development  process  as  described  in  earlier  sections. 
Initially,  program  performance  requirements  were  defined  and  specified 
in  XWS  13058.  These  provided  the  basis  for  the  specification  of  program 
design  requirements  in  XWS  9500.  Both  of  these  documents  served  as  man- 
agement tools  for  subsequent  program  implementation  phases.  Other  docu- 
mentation prepared  during  program  acquisition  included  a computer  pro- 
gram specification  package,  a common  data  base  design  document,  a com- 
puter operator's  manual,  a computer  program  evaluation  test  plan,  and  a 
fire  control  system  test  plan. 
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TABLE  2-5 

DLG-28  DFCS  ACQUISITION  MANAGEMENT 


Program  Manager 

NAVSEA  6541  (Terrier) 

System  Contractor 

APL  (ADM)  Vitro  (Production) 

Maintenance  Agent 

NSWC  Dahlgren 

Software  Deliverables 

Operational  Program  and  Pro- 
gram Documentation 

Validation  Agent 

APL/NSWC  Dahlgren  (approved 
NSWSES,  NAVSEA) 

Integration  Agent 

APL 

In-Service  Engineering 
Agent 

NSWSES 

In  general,  the  acquisition  task  was  accomplished  effectively 
and  with  few  major  problems.  Factors  contributing  to  the  overall  suc- 
cess of  the  development  effort  were  the  activities  of  the  DSC  and  the 
good  working  relationships  (both  formal  and  informal)  among  the  above- 
listed  organizations. 


2.7  OPERATIONAL  SOFTWARE  MAINTENANCE 

2.7.1  NTDS  Program  Maintenance 

After  production  versions  of  the  DLG  operational  program  were 
successfully  deployed,  FCDSSA(DN)  assumed  the  life-cycle  maintenance 
responsibility.  The  transfer  of  responsibility  within  FCDSSA(DN)  was 
orderly  due  mainly  to  FCDSSA(DN)  being  involved  from  the  program Ts  in- 
ception. Further  modifications,  including  Model  IV,  will  be  supervised 

by  FCDSSA(DN)  personnel.  Since  the  initial  program  was  taken  over  for 
maintenance,  the  program  has  developed  almost  entirely  under  the  aus- 
pices of  FCDSSA(DN) . 

2.7.2  DFCS  Program  Maintenance 

NSWC  Dahlgren  is  the  agent  responsible  for  the  DFCS  computer 
program  maintenance.  It  receives  assistance  in  this  effort  from  NSWSES, 
the  designated  In-Service  Engineering  Agent,  Vitro  also  provides  sup- 
port when  requested. 
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There  were  no  particular  problems  in  transferring  the  program 
to  the  maintenance  agent.  The  transfer  was  aided  by  the  fact  that  NSWC 
had  participated  in  the  software  validation  phase  at  the  APL  LBTS. 

A standard  TRIM  III  language  was  used  to  develop  the  program, 
and  NSWC  had  a compiler  available.  The  documentation  provided  to  NSWC 
was  adequate. 


2 . 8 HIGHLIGHTS 

DLG-28  was  the  first  operational  (1966)  combat  system  that  in- 
tegrated the  tactical  data  system  functions  with  weapon  direction  system 
functions  resulting  in  WDS  Mk  11.  Weapon  Systems  requirements  were  iden- 
tified by  both  the  NTDS  Program  Manager  and  the  Weapon  Systems  manager 
in  mutually  acceptable  requirements  documents.  (MP1) 

An  on-site  level-of-ef f ort  contract  allowed  close  working  re- 
lationships between  the  NTDS  contractor  and  the  development  agent.  Prob- 
lems were  easily  identified,  and  required  actions  were  taken  earlier  than 
would  have  been  possible  otherwise.  (MP1,MS2) 

The  NTDS  system  can  operate  at  reduced  capacity  with  only  two 
computers;  the  DFCS  system  can  operate  at  reduced  capacity  with  only  one 
computer.  (SE1 ,SE2) 

The  Dynamic  Modular  Replacement  (DMR)  technique  for  read-in 
of  alternate  program  modules  to  facilitate  different  combat  system  war- 
fare requirements  was  developed  for  these  ships.  (SE2) 

An  early  freeze  of  Data  Base  design  provided  stable  program 
development  control.  (SE3) 

Common  software  modules  were  developed  to  provide  compatibility 
among  ships  of  the  same  class  but  with  different  equipment  suites.  (SE3) 

The  DFCS  program  was  developed  and  validated  using  a land-based 
test  site  at  the  developer1 s site  (APL).  (IF3) 

Both  Navy  and  contractor  personnel  were  experienced  and  knowl- 
edgeable in  DLG  combat  system  operational  requirements.  This  enhanced 
development  by  exploiting  proven  development  techniques  and  avoiding 
previous  mistakes.  (MS2) 

A single  agent  was  responsible  for  life-cycle  maintenance  as 
well  as  modification  programming;  this  allowed  an  orderly  transition 
from  an  existing  program  to  a more  capable  program.  (MS3) 
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3.  DDG-9  COMBAT  SYSTEM 


3.1  GENERAL  SYSTEM  DESCRIPTION 

DDG-9  (USS  Towers)  is  one  of  29  Guided  Missile  Destroyers 
armed  with  the  Tartar  or  Standard  Missile  1 (SM-1)  Medium  Range  (MR) 
missile  Weapon  System.  DDGfs  2 through  24  were  "new  construction," 
whereas  DDG's  31  through  36  are  converted  Sherman/Mitscher  DDfs.  Four 
of  the  DDGTs,  the  C.  F.  Adams  Class,  are  provided  with  a Tactical  Data 
System  (TDS) . 

The  general  mission  of  the  Guided  Missile  Destroyer  is  to 
operate  offensively  with  strike  forces,  to  operate  with  hunter/killer 
groups,  to  support  amphibious  assault  operations,  and  to  screen  sup- 
port forces  and  convoys  against  submarine,  air,  and  surface  threats. 

The  major  subsystems  of  the  DDG-9  combat  system  are  the  sen- 
sor system,  the  combat  direction  system,  and  the  missile,  gun,  elec- 
tronic warfare,  and  antisubmarine  warfare  Weapon  Systems.  These  sub- 
systems are  integrated  into  the  total  combat  system  to  support  tactical 
operational  requirements  for  target  detection,  tracking,  identification, 
evaluation,  and  assignment  to  weapons  for  a controlled  engagement. 

3.1.1  Sensor  System 

The  primary  capability  for  detection,  tracking,  and  identifi- 
cation of  air  and  surface  targets  is  provided  by  the  search  radar  sys- 
tem and  its  associated  identification  friend  or  foe  (IFF)  equipments. 

The  DDG-9  is  equipped  with  a surface  search  radar  (AN/SPS-10C) , a three- 
coordinate  long-range  air-search  radar  (AN/SPS-39A) , and  a two-coordi- 
nate long-range  air-search  radar  (AN/SPS-29E) . The  IFF  capability  for 
the  DDG-9  is  provided  by  the  Automatic  Identification  Mk  XII  System 
(AIMS) . 


Video  processing  equipment  designated  as  the  Beacon  Video  Pro- 
cessor (BVP)  operates  on  IFF  data  to  provide  an  automatic  identification 
capability  for  friendly  aircraft.  The  BVP  is  also  supported  by  a sec- 
tion of  the  combat  direction  system  computer  operational  program. 

The  primary  capability  for  subsurface  target  detection  and 
tracking  on  the  DDG-9  is  provided  by  a sonar  detection  and  ranging  set 
(AN/SQS-23) . 

The  electronic  support  measures  (ESM)  functions  of  the  DDG-9 
are  provided  by  an  electronic  warfare  system  (AN/SLQ-26)  and  an  ESM  re- 
ceiver group  (OR-45/SLQ-19) . 
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3.1.2  Combat  Direction  System 

Combat  direction  functions  on  the  DDG-9  are  provided  by  the 
TDS.  The  primary  elements  of  the  TDS  are  a data  processing  system,  a 
display  system,  data  communications  equipments,  and  miscellaneous  data 
conversion  equipments. 

The  data  processing  system  includes  a general-purpose  digital 
computer  (AN/UYK-7) , associated  software,  and  various  peripheral  devices. 
The  communcations  system  includes  equipments  that  provide  the  capability 
for  the  DDG-9  to  participate  in  data  exchange  over  data  Link  11  (com- 
puter-to-computer  data  exchange  with  remote  units). 

3.1.3  Weapon  Systems 

The  primary  Weapon  System  aboard  the  DDG-9  is  the  Tartar 
guided  missile  system.  There  are  two  Missile  Fire  Control  Systems 
(MFCS)  (Mk  74  Mod  8);  each  is  supported  by  a general-purpose  digital 
computer  (Mk  152)  and  associated  software.  Missiles  are  launched  from 
a guided  missile  launching  system  (GMLS)  (Mk  11  Mod  0). 

The  DDG-9  gun  Weapon  System  consists  of  a gun  fire  control 
system  (Mk  68  Mod  8)  and  two  5"/54  gun  mounts. 

Antisubmarine  warfare  functions  are  supported  by  an  underwater 
battery  fire  control  group  (Mk  111),  ASROC  missiles  launched  from  an 
ASROC  launcher  (Launching  Group  Mk  16),  and  two  torpedo  tubes. 

Electronic  warfare  functions  are  supported  by  an  electronic 
countermeasures  (ECM)  set  (AN/ULQ-6B) . 

3.1.4  Acquisition  History 

The  DDG's  carrying  the  TDS  have  also  been  improved  by  the  addi- 
tion of  Digital  Fire  Control  Systems  (DFCS) . Additional  improvements 
will  include  Integrated  Automatic  Detection  and  Tracking  (IADT)  by  the 
addition  of  AN/SYS-1  IADT  processors. 


The  development  of  DFCS's  for  the  DDG's  was  initiated  in  1964. 
The  initial  design  was  based  on  the  use  of  the  CP-789/UYK.  As  develop- 
ment progressed,  the  capacity  of  the  CP-789  was  found  to  be  inadequate, 
and  the  CP-848/UYK  (Mk  152)  was  used.  First  installation  was  on  DDG-16 
in  1971,  with  all  the  DDG's  to  be  completed  by  1976. 

The  DDG  TDS  program  was  initiated  by  NAVORD  (Project  Manager) 
in  1969.  Naval  Ship  Engineering  Center  (NAVSEC)  was  designated  as  the 
Program  Development  Agency  (PDA) , with  Fleet  Combat  Direction  System 
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Support  Activity,  Dam  Neck  (FCDSSA(DN) ) as  the  TDS  agent  and  Univac  the 
prime  contractor  for  software  development.  Naval  Surface  Weapons  Center 
(NSWC)  (Dahlgren)  was  selected  as  the  NAVORD  agent  for  the  Tartar  Weapon 
Direction  System  (WDS)  with  Raytheon  as  the  prime  software  contractor. 

In  1970,  software  development  was  begun.  Upon  completion  of 
an  18-month  test  phase  at  Mare  Island  (November  1971-1973),  a perfor- 
mance test  (DS  659)  was  conducted  by  Operational  Test  and  Evaluation 
Force  (OPTEVFOR)  in  mid-1973  at  Mare  Island.  Final  Formal  Test  and  Ac- 
ceptance by  the  Navy,  conducted  at  FCDSSA(DN) , culminated  in  a 24-hour 
endurance  trial  in  early  1974.  The  Navy  accepted  the  Operational  Pro- 
gram (Version  0)  on  1 April  1974.  Version  2 has  now  been  accepted. 

Three  TDS  DDGfs  (12,  15,  and  21)  have  recently  completed  a successful 
7-month  tour  in  the  Pacific.  The  TDS  program  is  now  in  maintenance 
phase  at  FCDSSA(DN) . 

In  the  DDG-2  Class  Upgrade  Program,  these  ships  will  be  the 
first  to  incorporate  an  IADT  system,  the  AN/ SYS- 1.  This  system  will 
initially  provide  IADT  based  on  data  from  the  AN/SPS-52B (Mod) , AN/SPS- 
40C/D,  and  the  AN/SPS-58C.  Design  goals  for  the  future  include  the  in- 
corporation of  all  onboard  sensors  into  the  IADT  system. 

The  design  of  the  combat  system  for  the  DDG-2  Upgrade  will  use 
standard  general-purpose  consoles  and  computers  throughout  the  system. 

The  responsibility  for  the  development  and  implementation  of  the  com- 
plete combat  system  for  the  DDG  Upgrade  has  been  given  to  NAVSEA  6542. 

3.1.5  System  Diagram 

A system  block  diagram  of  the  DDG-9  combat  system  is  shown  in 
Fig.  3-1  indicating  the  functional  relationships  among  the  primary  sys- 
tem elements.  The  shaded  blocks  designate  the  functional  changes  for 
the  recently  approved  DDG  Upgrade  Program  scheduled  for  23  ships  (DDG's  2 
through  24).  The  characteristics  of  any  given  computer  (e.g.,  Wl)  are 
given  in  Table  3-1. 


3.2  COMPUTER  SYSTEM  ARCHITECTURE 

3.2.1  Computer  Characteristics 

The  DDG-9  combat  system  is  supported  by  three  general-purpose 
stored-program  digital  computers  specifically  designed  for  use  in  real- 
time military  applications.  These  are  an  AN/UYK-7  and  two  CP-848/UYK 
computers,  both  manufactured  by  Univac.  Computer  characteristics  and 
operational  functions  are  given  in  Table  3-1  for  DDG-class  ships. 
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Fig.  3-1  DDG-9  Combat  System 


TABLE  3-1 

DDG-9  COMPUTER  SUMMARY 


Unit 

Type 

Function 

Pro- 

cessor 

Memory 

C 

AN/UYK-7 

(32  bit,  1.5  vs) 

Tactical  data  processing: 
detect  and  track  from  beacon 
and  2D  radar  data,  rate-aided 
track,  threat  identification 
and  evaluation,  weapon  assign- 
ment, link  communication 

1 

48k 

W1 

CP-848/UYK  (Mk  152) 
(18  bit,  2 vs) 

Missile  fire  control/weapon 
direction 

1 

48k 

m 

CP-848/UYK  (Mk  152) 
(18  bit,  2 vs) 

Missile  fire  control/weapon 
direction 

1 

48k 
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The  AN/UYK-7  makes  use  of  modular  construction  and  consists 
of  a central  processor,  an  input/output  (I/O)  controller,  an  I/O  adapter, 
a power  supply,  and  three  memory  modules  of  16k  words  each.  The  UYK-7 
has  a word  length  of  32  bits  and  a memory  cycle  time  of  1.5  ys. 

The  two  CP-848/UYK  computers  communicate  directly  with  each 
other  via  an  intercomputer  I/O  channel  pair.  The  CP-848  computer  is 
also  called  the  Univac  1219B  (militarized  version)  or  more  frequently 
the  Mk  152  Mod  1.  The  Mk  152  aboard  the  DDG-9  has  a 48k  word  memory,  a 
word  length  of  18  bits,  and  a memory  cycle  time  of  2 ys. 

The  general-purpose  digital  computers  aboard  the  DDG-9  are 
supported  by  the  following  standard  Navy  computer  peripheral  equipments: 

1.  AN/UYK-7  Computer  Peripheral  Equipment 

Data  Exchange  Auxiliary  Console  (DEAC)  (OJ-172/UYK)  — com- 
prised of  two  magnetic  tape  transports,  a paper  tape  punch 
and  reader  unit,  and  a teletype  keyboard  printer  unit,  all 
of  which  operate  on  a single  computer  I/O  channel. 

2 . Mk  152  Computer  Peripheral  Equipment 

Input/Output  Console  Mk  77  — comprised  of  a paper  tape 
perforator,  a paper  tape  reader,  a page  printer,  and  an 
alphanumeric  keyboard,  all  of  which  operate  on  a single 
computer  I/O  channel  (Univac  1532). 

For  conditions  of  Mk  77  casualty,  the  magnetic  tape  unit 
of  the  DEAC  can  be  used  to  load  the  Mk  152  operational 
programs. 

3.2.2  Functional  Allocation  among  Computers 

The  AN/UYK-7  computer  is  the  major  element  of  the  TDS , which 
has  the  primary  responsibility  for  DDG-9  combat  direction  functions. 

The  UYK-7,  supported  by  a tactical  operational  program,  provides  the 
data  processing  capability  required  to  collect,  correlate,  and  evaluate 
track  data  input  from  combat  system  sensor  equipments.  Through  operator 
interaction  with  the  program  via  a display  system  complex,  the  TDS  pro- 
vides the  operational  capabilities  required  to  effectively  respond  to 
hostile  tactical  environments.  In  addition  to  its  primary  combat  di- 
rection functions,  the  TDS  is  also  responsible  for  data  processing  asso- 
ciated with  the  Radar  Video  Processor  (RVP)  and  the  BVP. 
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Each  of  the  two  Mk  152  (CP-848)  computers  is  a part  of  a Tar- 
tar missile  fire  control  system.  Together  with  its  associated  software, 
the  Mk  152  is  responsible  for  the  performance  of  the  basic  computations 
required  to  engage  targets  with  missiles,  according  to  a designated  op- 
erational mode.  This  includes  processing  required  for  fire  control 
radar  designation,  missile  launcher  control,  and  other  functions  that 
may  be  necessary  to  acquire,  track,  and  engage  targets  of  interest. 

Also  resident  in  the  Mk  152  computer  are  the  program  functions  neces- 
sary to  support  weapon  direction  requirements  for  the  Tartar  missile 
fire  control  system  and  the  gun  fire  control  system.  This  part  of  the 
system  is  designated  as  WDS  Mk  13  Mod  1. 

3.2.3  Interrelation  among  Computers 

The  interface  configuration  of  DDG-9  computers  is  shown  in 
Fig.  3-1.  The  two  Mk  152  computers  communicate  directly  with  each  other 
over  intercomputer  I/O  channels.  The  TDS  UYK-7  computer  communicates 
with  one  of  the  Mk  152  computers  over  an  intercomputer  I/O  channel  pair. 
This  Mk  152  is  designated  as  the  '’primary11  missile  fire  control  system 
computer  and  is  the  one  having  responsibility  for  processing  weapon  di- 
rection functions. 

A switching  arrangement  among  the  three  computers  allows  either 
Mk  152  to  operate  as  the  primary  missile  fire  control  computer.  This 
provides  a casualty  capability  in  the  event  of  the  loss  of  the  Mk  152 
designated  as  the  primary  computer.  A limited  capability  for  driving 
consoles  can  be  supported  by  the  WDS  area  of  the  primary  Mk  152  in  the 
event  of  an  AN/UYK-7  casualty. 

3.2.4  Functional  Interfaces  With  Sensors 

The  TDS  has  the  primary  responsibility  for  the  tactical  pro- 
cessing of  data  derived  from  the  DDG-9  sensor  systems.  Search  radar 
data  are  input  to  the  TDS  operational  program  manually  via  operator  ac- 
tion at  a general-purpose  display  console.  Automatic  input  of  selected 
IFF  data  is  accomplished  through  the  BVP  equipments.  ESM  data  and  sonar 
data  are  entered  via  the  signal  conversion  equipments  of  the  Integrated 
Circuit  Keyset  Central  Multiplexer  (ICKCMX) . Figure  3-1  shows  the 
major  computer  system/sensor  system  interfaces  for  the  DDG-9. 
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3.2.5  Functional  Interfaces  With  Weapons 

The  TDS  also  has  the  primary  responsibility  for  initiating  and 
controlling  weapon  responses  to  threats.  Communication  between  the  TDS 
UYK-7  and  both  the  Tartar  missile  system  and  the  gun  system  is  accom- 
plished via  the  primary  Mk  152  computer.  This  computer  transfers  the 
appropriate  TDS  data  to  the  other  Mk  152.  Communication  between  the 
Mk  152  computers  and  the  associated  weapon  fire  control  system  elements 
is  accomplished  via  the  signal  conversion  equipments  of  the  Signal  Data 
Converter  Mk  72.  Communication  between  the  TDS  UYK-7  and  both  the  elec- 
tronic warfare  and  antisubmarine  warfare  systems  is  accomplished  via  the 
signal  conversion  equipments  of  the  ICKCMX.  Figure  3-1  shows  the  pri- 
mary computer  system/Weapon  System  interfaces  for  the  DDG-9. 


3.3  COMPUTER  PROGRAM  ARCHITECTURE 

3.3.1  Tactical  Data  System  Computer  Program 

The  DDG-9  TDS  computer  program  is  identified  as  a Model  III 
Computer  Operational  Program.  Operational  programs  of  a given  model 
communicate  via  digital  data  links  with  other  TDS  programs  of  the  same 
model.  All  current  Navy  TDS  programs  in  operational  use  are  Model  III 
programs. 


3.3.2  Tactical  Data  System  Program  Architectural  Structure 

The  TDS  program  structure  is  highly  modular  in  form.  Each 
module  consists  of  a local  data  segment  and  an  instruction  segment  con- 
taining three  logical  entry  points  for  priority,  message,  or  periodic 
processing  requirements.  A bare  minimum  of  three  modules,  collectively 
referred  to  as  the  "Common  Program,"  is  required  for  program  cycling. 
Other  individual  modules  provide  individual  functions,  such  as  tracking, 
beacon  video  processing,  or  radar  video  processing,  and  may  be  operator 
selected  to  form  the  desired  operational  program  conf iguration . As  in- 
dividual modules  are  called  into  the  computer  from  program  tape,  the 
instruction  and  data  segments  are  respectively  placed  in  low  and  high 
core  addresses  to  take  advantage  of  UYK-7  memory  accessing  time  savings. 

UYK-7  computer  architecture  is  also  utilized  to  separate  pro- 
gram executive  processing  from  other  processes  by  executing  the  Common 
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Control  module  instructions  while  within  the  UYK-7  Executive  state.  All 
I/O  functions,  message  scheduling,  and  module  calls  are  performed  within 
the  Common  Control  module  in  the  Executive  machine  state.  Other  pro- 
cessing is  performed  using  the  Task  state  registers  and  Task  operating 
mode  of  the  UYK-7. 

A common  data  base  and  assemblage  of  utility  routines  (other 
than  I/O)  are  provided  by  the  Common  System  module.  This  module  may  be 
accessed  by  any  other  module  in  the  program. 

3.3.3  Tactical  Data  System  Executive  Program 

The  Executive  function  of  the  TDS  program  provides  for  all 
program  interrupt  handling  (including  clock,  I/O,  and  function  requests 
from  Task  state  processing),  scheduling,  and  module  calling  (priority, 
message,  and  periodic). 

In  essence,  the  Executive  is  entirely  interrupt-driven.  I/O 
requests  and  message  packing  are  performed  from  Task  state  programs  by 
setting  the  appropriate  interrupt  codes  and  causing  an  internal  inter- 
rupt to  enter  the  Executive  state  where  the  desired  function  is  per- 
formed. Normal  returns  to  the  executive  from  module  processing  (Task 
state)  are  performed  in  a similar  manner. 

3.3.4  Tactical  Data  System  Equipment  Interfaces 

The  TDS  computer  program  communicates  with  the  equipment  de- 
scribed in  the  following  paragraphs  via  the  I/O  channels  of  the  UYK-7. 

1.  Link  11 

The  TDS  interface  with  Link  11  equipment  is  supported  by 
the  Link  11  module,  using  a single  I/O  channel  and  I/O 
data  buffers  within  the  TDS  computer. 

2.  Beacon  Video  Processor 


Control  of  BVP  interrogation  and  the  correlation  of  BVP 
reports  with  tracks  is  performed  by  the  TDS  within  the  BVP 
module.  This  is  accomplished  using  a single  I/O  channel 
and  alternating  input  buffers  and  external  function  out- 
puts. 
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3.  Radar  Video  Processor  (Experimental;  not  part  of  the  op- 
erational program) 

2D  radar  hit  centroids  from  either  the  long-range  search 
radar  or  the  surface  search  radar  (not  both)  are  input  in 
real-time  to  the  TDS  computer  program  and  processed  for 
clutter  correlation  by  the  TDS  RVP  module.  Centroids 
passing  a clutter  censor  process  are  transferred  to  an  in- 
ternal interface  buffer  for  use  by  the  tracking  module  in 
updating  existing  tracks  or  in  the  generation  of  new  tracks. 
The  clutter  map  generated  and  updated  within  the  RVP  module 
may  be  displayed  on  a display  console  PPI. 

4.  Pulse  Amplifier/Symbol  Generator 

The  Display  module  within  the  TDS  program,  using  a single 
I/O  channel,  handles  communications  to  and  from  the  display 
consoles  via  a Pulse  Ampl if ier/ Symbol  Generator  (PA/SG). 
Symbols  displayed  on  the  consoles  are  refreshed  by  con- 
tinual outputs  of  the  TDS  display  buffer  to  the  PA/SG. 
Additional  TDS  outputs  to  the  PA/SG  control  the  console 
data  readout  lamps  and  pushbutton  legends.  The  PA/SG  is 
also  interrogated  periodically  to  detect  console  operator 
pushbutton  actions. 

5 . Data  Exchange  Auxiliary  Console 

All  input  and  output  to  the  DEAC  is  controlled  by  the  TDS 
program  DEAC  Interface  module.  These  I/O  functions  handle 
a dual-drive  magnetic  tape  unit,  a teletype  printer  and  key- 
board, and  a paper  tape  reader  and  punch.  The  DEAC  is  used 
for  program  loading,  program  reconfiguration,  and  data  ex- 
traction . 

6.  Integrated  Circuit  Keyset  Central  Multiplexer 

Input  and  output  to  the  ICKCMX  is  performed  by  the  TDS  pro- 
gram Converter  module  using  a single  I/O  channel  and  single 
word  buffers.  Data  input  from  the  ICKCMX  include  ship's 
heading,  speed,  pitch,  roll,  underwater  battery  data,  and 
ESM  data. 

7.  Missile  System  (Mk  74  Mod  8/WDS  Mk  13  Mod  1) 

The  TDS  program  interface  with  the  MFCS  is  supported  by 
the  Threat  Response  module  and  consists  of  a single  I/O 
channel  to  one  of  the  two  Mk  152  computers.  Targets  sent 
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to  the  MFCS  from  the  TDS  are  scheduled  by  the  WDS  Mk  13 
Mod  1 portion  of  the  MFCS  for  possible  engagement. 

Schedule  information  is  sent  back  to  TDS  for  display  and 
operator  modification,  if  necessary.  Schedule  execution, 
individual  target  actions,  and  engage  missile  orders  are 
sent  to  the  MFCS  by  the  TDS  to  conduct  radar  assignments 
or  other  necessary  actions. 

3.3.5  Tactical  Data  System  Module  Functions 

Table  3-2  provides  brief  descriptions  and  approximate  core 
sizes  for  the  TDS  program  modules.  Not  all  modules  may  be  resident  in 
the  TDS  computer  at  the  same  time  due  to  core  limitations.  Manual  op- 
erations at  the  DEAC  are  required  to  configure  the  program  with  the  de- 
sired program  modules. 

3.3.6  Missile  Fire  Control  System  Computer  Program 

An  identical  computer  program  resides  in  each  of  the  two 
Mk  152  (CP-848)  computers  comprising  the  Mk  74  Mod  8/WDS  Mk  13  Mod  1 
MFCS  for  the  DDG-9.  Within  each  program  there  are  two  basic  modules. 
These  are  the  Mk  74  Mod  8 module,  which  drives  a director  and  performs 
the  tracking  function,  and  a WDS  Mk  13  Mod  1 module,  which  contains 
target  scheduling  algorithms,  casualty  display  routines,  and  system 
operability  tests. 

3.3.7  Missile  Fire  Control  System  Program  Architectural  Structure 

The  Mk  152  computer  connected  to  the  TDS  computer  is  con- 
sidered the  primary  fire  control  system  computer.  The  WDS  scheduling 
function  is  performed  within  that  computer.  In  the  other,  the  secondary 
computer,  operability  tests  are  executed  upon  operator  demand.  In  nor- 
mal operation,  designation  and  repeat-back  data  are  passed  via  an  I/O 
channel  from  one  computer  to  the  other.  When  a switch  is  made  causing 
the  secondary  Mk  152  to  become  the  primary  computer,  the  TDS  sends  all 
designation  data  required  to  initialize  the  scheduling  algorithms  in 
the  ’’new"  primary  computer.  Scheduling  these  operations  ceases  in  the 
secondary  computer.  Both  modules  reside  within  the  same  computer  at 
the  same  time;  they  are  arranged  sequentially  with  the  Mk  74  module 
occupying  12k  of  lower  memory,  followed  by  the  Mk  13  module. 

Within  each  module  are  subprograms  which  are  executed  to  pro- 
vide the  necessary  program  functions.  These  subprograms  are  basically 
closed  subroutines  in  that  they  have  unique  entry  and  exit  points. 

Since  no  artificial  entry  restrictions  are  imposed,  it  is  possible  for 
one  subprogram  to  call  another  directly  as  needed. 
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TABLE  3-2 

DDG-9  TDS  MODULE  DESCRIPTIONS 


Module  Name 

Brief  Description 

Core 

Allocation 

Beacon  Video 

Provides  processing  required  to  schedule  and  control  IFF/SIF 
(selected  identification  feature)  interrogations  and  provides 
interface  with  BVP  equipments. 

2500 

Air/Surface 

Maneuvering 

Supports  air  control  and  surface  operations  of  the  combat 
system. 

3000 

Common  Program 

Includes  common  control,  systems  control,  and  DEAC  interface 
modules.  These  modules  function  to  support  coordination  and 
control  of  program  operation. 

3960 

Common  System 

Contains  utility  routines  and  common  data  stores. 

4200 

Combat  System 
Alignment  Test 

Supports  alignment  testing. 

6000 

Combat  System 
Interface  Test 

Supports  interface  testing. 

6000 

Combat  System 
Operability  Test 

Supports  operability  testing. 

6000 

Converter 

Supports  the  interface  with  ICKCMX. 

1000 

Display 

Supports  the  interface  between  the  TDS  program  and  the  dis- 
play consoles. 

6000 

Electronic  Warfare 

Provides  an  interface  between  the  TDS  program  and  the  ship’s 
EW  systems. 

4000 

Link  11 

Provides  an  interface  with  Link  11  terminal  equipment  and 
other  TDS  program  modules. 

4000 

Navigation 

Maintains  ownship  navigation  data  and  calculates  ship  position 
and  velocity. 

650 

Radar  Video 
Processing 

Processes  digitized  video  received  from  RVP  equipments. 
Assembles  and  transmits  track  reports  to  the  Tracking  module. 

8500 

Threat  Response 

Supports  combat  system  weapon  assignment  and  weapon  control 
functions  and  provides  an  interface  with  the  missile  systems, 
the  gun  system,  and  the  underwater  battery  system. 

8000 

Tracking 

Supports  combat  system  tracking  tasks  for  both  manual  and 
automatic  track  position  entries. 

2500 

*Experimental 
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Basic  program  execution  is  determined  by  a small  executive 
program  interrupted  by  the  computer  clock  at  1 ms  intervals  in  order 
to  regulate  execution  rates  and  monitor  execution  overflows. 

3.3.8  Missile  Fire  Control  System  Executive  Program  Functions 

Due  to  the  sampling  nature  and  other  requirements  of  the 
radar  directing  process,  the  program  executive  is  clock  regulated.  A 
basic  execution  period  of  32  ms  is  divided  among  three  major  program 
functions:  Mode  and  I/O,  Radar  Control,  and  Digital  System  Operability 

Test  (DSOT)/WDS.  Each  major  function  is  allocated  a fixed  portion  of 
this  32  ms  period,  with  a maximum  of  2 ms  allowable  for  overrun.  If  a 
major  function  exceeds  the  overrun,  its  processing  is  terminated,  a com- 
puter fault  light  is  lit,  and  the  next  major  function  is  initiated. 

Any  processing  that  is  terminated  due  to  time  overrun  is  left  incom- 
plete for  the  rest  of  the  32  ms  time  cycle.  It  is  not  continued  at 
the  termination  point  in  the  next  time  cycle  but  rather  started  anew. 

The  major  functions  of  Mode  and  Radar  Control  pertain  basi- 
cally to  FCS  operations  and  are  allocated  approximately  half  of  the 
32  ms  execution  period.  Radar  direction,  tracking,  and  control  I/O  is 
performed  in  this  period.  The  remaining  time  is  allocated  to  the  DSOT/ 

WDS  function.  WDS  functions  are  executed  if  the  computer  is  the  pri- 
mary computer,  and  DSOT  functions  are  executed  if  the  computer  is  the 
secondary  computer.  Within  the  WDS  function  is  a secondary  execution 
program  that  further  directs  subprogram  execution,  since  not  all  WDS 
processing  (target  scheduling  etc.)  is  performed  each  WDS  period,  as 
are  the  radar  processing  functions. 

3.3.9  Missile  Fire  Control  System  Equipment  Interfaces 

The  fire  control  system/WDS  program  communicates  with  the  on- 
line equipment  described  in  the  following  paragraphs: 

1.  Signal  Data  Converter  (Mk  72) 

A single  digital  channel  is  used  for  input  and  output 
from  each  Mk  152  computer  to  an  associated  Signal  Data 
Converter  for  communication  with  a missile  radar,  a direc- 
tor, the  launcher,  the  Launcher  System  Module  Console  (LSMC) , 
and  the  gun  fire  control  system.  Common  program  routines 
handle  the  necessary  I/O  from  different  portions  of  the 
Mk  152  computer  program.  Most  input  is  performed  within 
the  Mode  function,  while  most  output  is  performed  as 
needed  within  the  Radar  Control  function. 
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2 . Tactical  Data  System 

Dual-channel  intercomputer  I/O  between  the  primary  Mk  152 
and  the  TDS  UYK-7  computer  provides  for  the  normal  com- 
mand and  control  target  designation  path.  Either  of  the 
two  Mk  152  computers  may  be  switched  to  the  TDS  to  act 
as  the  primary  Mk  152. 

3.  Pulse  Amplifier/Symbol  Generator 

The  WDS  interface  with  the  PA/S G is  performed  in  TDS 
casualty  situations  using  the  dual  I/O  channels  from  the 
primary  Mk  152  that  are  normally  assigned  to  the  TDS.  A 
manual  switch  operation  allows  the  WDS  to  drive  two  dis- 
play consoles  to  provide  reduced  capability  combat  sys- 
tem operations.  In  this  situation,  subprograms  within 
the  WDS  are  called  upon  to  refresh  displays  and  interro- 
gate console  inputs,  and  to  respond  to  operator  pushbut- 
ton actions.  Manual  tracking  functions  are  also  enabled. 

4 . Mk  152  Computer 

An  intercomputer  I/O  channel  is  used  to  link  the  two  Mk 
152  computers  together  for  exchange  of  fire  control  sys- 
tem repeat-back  data  and  designation  data. 

3.3.10  Missile  Fire  Control  System  Subprogram  Functions 

Table  3-3  provides  brief  descriptions  and  approximate  core 
sizes  for  the  major  subprograms  of  the  Mk  152  computers.  All  subpro- 
grams are  resident  in  each  of  the  two  Mk  152  computers. 

3.4  SOFTWARE  DEFINITION,  DESIGN,  AND  IMPLEMENTATION 

3.4.1  Tactical  Data  System  Program  Definition,  Design,  and  Imple- 

mentation 

The  TDS  for  the  DDG  was  generally  defined  by  NAVSHIPS  docu- 
ments that  existed  prior  to  the  implementation  of  the  DDG  version  of 
the  TDS.  Such  documents  included  functional  requirements,  software 
specifications,  hardware  and  software  standards,  and  certain  design 
diagrams  and  documents. 

At  the  time  the  software  implementation  was  under  way  for  the 
TDS,  there  was  no  computer-aided  design  effort  applied  to  this  effort. 
Since  a high-level  compiler  was  not  ready  for  use  in  1971,  a low-level 
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TABLE  3-3 

DDG-9  MFCS/WDS  SUBPROGRAM  DESCRIPTIONS 


Subprogram  Name 

Brief  Description 

Core 

Allocat ion 

Clock  and  I/O 

Directs  program  execution  and  handles  I/O. 

828 

Common  Math 

Common  mathematical  routines. 

331 

Common  Constants 

Common  fixed  data  storage  area. 

1048 

Common  Variables 

Common  variable  data  storage  area. 

1017 

Mode 

Determines  proper  radar  state  —designate,  track,  etc. 

1802 

Radar  Control 

Controls  and  instructs  radar  directors. 

125  5 

Angle  Tracker 

Performs  angle  tracking  functions. 

640 

SIMUBR 

Test  simulation. 

712 

PR R 

Decision  for  Pulse  Repetition  Rate,  selection. 

587 

Weapons 

Handles  weapons  allocation  functions. 

1462 

Tracking  Modifier 

Modifies  tracking  algorithms. 

890 

Engageability 

Determines  target  engageability. 

2648 

WDS  Tracker 

Smooths  data  for  scheduling. 

1040 

PACILR 

Packing  routines. 

315 

NORMGR 

Track  data  update. 

62 

WDS  Data  Base 

WDS  data  storage  area. 

2504 

(radar  files)* 

Radar  data  storage  area. 

492 

(track  files)* 

Designation  track  data  files. 

857 

Reflected 

Engageability  Data 

Engageability  data. 

415 

WDS  Executive 

Directs  execution  of  WDS  subprograms. 

2061 

Queue  Verification 

Tests  targets  in  queue. 

582 

*(  ) generic  term 
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Table  3-3  (contfd) 


Subprogram  Name 

Brief  Description 

Core 

Allocation 

LS  Assignment 

Controls  launcher  system  assignment. 

143 

LSMC/LS  Signal 
Processing 

Processes  launching  system  signals. 

671 

Console  Control 

Interfaces  with  PA/SG  during  TDS  casualty. 

3436 

Display  Decisioner 

Handles  display  functions. 

517 

Schedular 

Initialization 

Initializes  WDS  scheduler. 

121 

Recommended  Schedule 

Contains  recommended  schedule. 

205  5 

Trial  Intercept/ 
Engagement  Display 

Performs  trial  intercept  and  engagement  display. 

394 

Executed  Schedule 

Contains  schedule  to  be  executed. 

1345 

Designation  Update 

Updates  designation  data. 
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language,  ULTRA  32  (later  a part  of  the  CMS-2Y  assembler),  was  used  to 
accomplish  all  the  assembly  operations.  The  debug  facilities  (software 
program  checkout)  were  located  at  Mare  Island,  the  land-based  test  site 
for  approximately  18  months.  The  programming/checkout  involved  four  to 
eight  persons  during  the  implementation  effort.  Computer  simulation 
was  used  to  provide  the  communications  Link  environment  etc.  Also,  the 
Junior  Participating  System  was  simulated  on  the  CP-642  computer  with 
the  Tartar  and  Link-endaround  simulations  included.  There  was  no  time 
sharing  in  the  TDS,  and  the  computer  software  programs  were  compiled  on 
the  machine  in  the  batch  mode. 

The  software  architecture  was  organized  in  a generally  top- 
down  manner  with  an  executive  to  control  the  system  from  the  top  with 
program  modules  designed  for  each  function.  Structured  programming  was 
not  used,  and  there  were  no  programmer  teams  involved  in  the  effort. 

One  individual  was  assigned  to  each  module,  and  one  maintenance  pro- 
grammer was  designated  to  patch  the  programs  during  checkout.  An  open 
shop  was  maintained  initially  where  the  programmers  could  exercise 
"hands-on"  operation  of  the  computer  during  their  program  checkout. 

Later  a closed  shop  compiler  operation  led  to  better  reliability  in  pro- 
gram implementation  and  debug. 

In  order  to  obtain  continuity  among  different  ship  systems, 
the  standard  algorithms  were  made  available  to  the  software  implemen- 
ted. In  this  manner  the  tracking  module,  utility  module,  etc.  could 
accomplish  the  same  results  regardless  of  the  specific  equipment  in- 
volved. It  was  noted  that  the  cross-fertilization  of  library  facili- 
ties is  best  enhanced  when  close  communication  among  the  participants 
is  maintained. 

One  outstanding  feature  of  the  software  development  process 
was  the  method  of  recording  program  patches.  A module  was  designated 
and  designed  for  the  specific  purpose  of  intercepting  patch  information 
when  a program  was  actually  being  corrected.  The  program  intercepted 
the  patch  information,  stored  it  in  a data  file,  and  printed  it  out  to 
be  read.  This  process  provided  a tremendous  aid  in  keeping  track  of 
program  changes  and  the  information  required  to  incorporate  permanent 
changes  into  the  program  at  a later  date.  Another  excellent  means  of 
finding  and  correcting  program  errors  was  the  generation  of  Program 
Trouble  Reports  (PTR's).  These  reports  were  used  by  those  individuals 
from  FCDSSA  who  were  performing  the  software  testing  procedures.  The 
PTRfs  provided  a permanent  record  of  trouble  areas  in  the  programs  and 
the  actions  taken  to  solve  the  problems. 

3.4.2  Fire  Control  System  Program  Definition,  Design,  and 

Implement  at ion 

The  functional  requirements  for  the  Mk  74  Guided  Missile  Fire 
Control  System  for  the  DDG  were  described  in  Performance  Specification 
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XWS  13917.  This  document  was  designed  along  the  guidelines  described 
in  WS  8506.  An  Interface  Design  Specification  (IDS)  was  developed  dur- 
ing the  same  time  frame  as  Performance  Specification  XWS  13917. 


Because  there  was  no  high-level  language  capability  available 
during  the  software  implementation,  the  programming  was  accomplished 
in  TRIM  III,  an  assembly— level  language.  This  assembler  was  modified 
somewhat  to  work  on  the  development  agency  equipment.  The  development 
agency  had  the  computer,  radars,  signal  data  converters,  etc.  avail- 
able in-house  to  accomplish  their  compiling/assembling,  debugging,  and 
certain  levels  of  testing. 

The  implementation  effort  was  organized  such  that  the  con- 
struction was  basically  top  down  in  design.  Essentially,  a design  engi— 
neer/programmer  was  assigned  to  each  subprogram.  A lead  design  engineer/ 
programmer  was  responsible  for  a program  and  was  also  responsible  for 
the  integrity  of  design  of  his  particular  program. 


3.5  SOFTWARE  VALIDATION  AND  INTEGRATION 

3.5.1  Tactical  Data  System  Program  Validation  and  Integration 

Three  different  organizations  (Raytheon,  Univac,  and  FCDSSA) 
participated  in  the  program.  The  PTR's,  described  earlier,  were  used 
as  guides  for  configuration  control  instead  of  the  IDS's  due  to  the  high- 
level  character  of  the  IDS. 

The  integration  facilities  were  installed  at  the  land-based 
test  site  at  Mare  Island.  There  were  also  facilities  for  input/output 
simulation  as  well  as  system  integration. 

The  LOGICON  ASMD  SIM  program  was  used  during  checkout  at 
FCDSSA(DN)  to  provide  targets.  This  simulation  does  an  excellent  job 
and  requires  two  CP-642B  computers.  The  Link  11  ALMON  (A-Link  monitor), 
using  an  additional  CP-642B  computer,  was  employed  to  simulate  Link  11. 

The  integration  testing  was  under  the  auspices  of  OPTEVFOR. 

3.5.2  Fire  Control  System  Program  Validation  and  Integration 

Each  program  underwent  a series  of  steps  for  test  and  valida- 
tion. First,  the  design  engineer/programmer  wrote  his  particular  pro- 
gram and,  operating  in  an  open  shop  environment,  stepped  his  program 
through  the  computer  in  order  to  make  corrections  etc.  The  program  was 
then  presented  to  the  lead  engineer  for  his  verification  and  approval  and 
delivered  to  the  test  site  (which  included  the  radars  etc.)  for  further 
testing.  The  next  step  in  the  process  was  to  take  the  program  to  Dahlgren 
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to  be  run  against  a Command  and  Control  simulation.  After  this  step, 
the  program  went  to  Mare  Island  to  be  processed  and  tested  in  the  inte- 
grated program.  After  this  phase,  Naval  Ship  Weapons  Systems  Engineer- 
ing Station  (NSWSES)  assumed  the  responsibility  for  the  system  perfor- 
mance testing. 


3.6  SOFTWARE  ACQUISITION  MANAGEMENT  ORGANIZATION  AND  METHODS 

3.6.1  Tactical  Data  System  Acquisition  Management 

The  organization  for  the  software  management  functions  deal- 
ing with  the  acquisition  etc.  of  the  TDS  software  (Table  3-4)  was  headed 
by  NAVORD  which  acted  at  the  Program  Office  level.  NAVSEC  was  funded 
for  its  participation  under  the  Antiship  Missile  Defense  (ASMD)  office. 
The  system  software  contractor  was  Univac.  NSWSES  was  assigned  the  re- 
sponsibility for  the  performance  testing  of  the  complete  system  (includ- 
ing the  FCS). 


TABLE  3-4 

DDG-9  TDS  MANAGEMENT  INFORMATION 


Program  Manager 
System  Contractor 
Type  Contract 
Program  Status 
Maintenance  Agent 
Software  Deliverables 
Validation  Agent 
Integration  Agent 


NAVSEA  6542  (Tartar) 
Univac 

Cost  Plus  Fixed  Fee 
Deployed 
FCDSSA(DN) 
Operational  Program 
FCDSSA(DN) 

NSWSES 


3.6.2  Fire  Control  System  Acquisition  Management 

The  FCS/WDS  management  information  is  given  in  Table  3-5.  The 
Tartar  Office  within  NAVORD  controlled  the  DDG  program.  The  system  con- 
tractor, Raytheon,  was  the  contractor  for  the  FCS  computer  software. 

The  organization  was  set  up  for  Raytheon  to  report  to  NSWC  who  served  as 
the  Government  laboratory  and  also  was  responsible  for  program  mainte- 
nance . 
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TABLE  3-5 

DDG-9  FCS/WDS  MANAGEMENT  INFORMATION 


Program  Manager 
System  Contractor 
Type  Contract 
Program  Status 
Maintenance  Agent 
Software  Deliverables 
Validation  Agent 
Integration  Agent 


NAVSEA  6542  (Tartar) 
Raytheon 

Cost  Plus  Fixed  Fee 
Deployed 
NSWC  Dahlgren 
Operational  Program 
NSWC  Dahlgren 
NSWSES 


The  management  documents  for  the  FCS  consisted  of  Performance 
Specification  XWS  13917,  which  is  discussed  above.  The  interface  coor- 
dination documents  consisted  of  the  IDS,  also  discussed  above. 

The  software  was  developed  by  the  system  contractor  who  exer- 
cised the  internal  design  audit  and  review  process  and  also  controlled 
the  software  configuration  with  its  associated  engineering  change  pro- 
cedures. Progress  measurement  and  monitoring  were  accomplished  by  op- 
erational and  integration  tests  performed  at  Mare  Island.  Program 
changes  and  modifications  consisted  of  PTR!s  which  were  sent  to 
FCDSSA(DN)  and  forwarded  to  NSWC  for  implementation. 

The  weapon  system  test  and  evaluation  procedures  were  exer- 
cised at  Mare  Island  where  the  integration  of  all  the  components  took 
place.  NSWSES  assumed  the  role  of  systems  integration  tester  and  per- 
formed those  tests.  The  total  system  installation  at  Mare  Island  pro- 
vided the  testing  environment. 


3.7  OPERATIONAL  SOFTWARE  MAINTENANCE 

3-7.1  Tactical  Data  System  Operational  Software  Maintenance 

The  maintenance  facility  for  the  TDS  program  is  FCDSSA(DN) . 
The  operational  software,  after  undergoing  16-  and  24-hour  endurance 
tests,  was  transferred  to  FCDSSA(DN)  for  implementation  and  mainte- 
nance. Version  0 was  accepted  on  1 April  1974  and  Version  2 has  now 
been  accepted.  The  computer  programming  language  used  for  this  ef- 
fort was  ULTRA  32/CMS-2Y  assembler,  as  discussed  previously.  There 
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were  no  problems  involved  with  the  dialects  of  the  language.  It  was 
estimated,  however,  that  had  the  Y compiler  been  used  alone,  rather 
than  ULTRA  32  alone,  20%  additional  code  would  have  been  generated. 

The  updating  and  maintenance  functions  have  been  designated  to 
FCDSSA(DN) , which  controls  the  procedure  for  implementing  changes  into 
existing  Fleet  units. 

3.7.2  Fire  Control  System  Operational  Software  Maintenance 

It  appears  that  there  were  no  major  problems  involved  in 
transferring  the  software  to  Government  control.  The  program  change 
procedure,  as  described  above,  involves  first  the  generation  of  a PTR 
which  is  sent  to  FCDSSA(DN)  and  forwarded  to  NSWC  at  Dahlgren  to  be  im- 
plemented. The  operational  maintenance  responsibility  rests  ultimately 
at  NSWC  to  maintain  and  modify  the  computer  software  programs. 


3.8  HIGHLIGHTS 

The  FCS/WDS  program  was  developed  in  accordance  with  WS  8506. 

(AP2) 

The  use  of  general-purpose  consoles  and  computers  (commonality 
of  equipment)  simplified  program  design  effort.  (SE1) 

The  WDS  Mk  13  Program  was  the  first  to  incorporate  an  equip- 
ment scheduler  that  provides  the  FCS  coordinator  with  a recommended  en- 
gagement schedule.  If  ordered  (by  the  FCS  coordinator)  to  execute  the 
schedule,  the  program  controls  the  assignments  of  fire  control  radars 
to  targets  and  the  loading  and  assignment  of  the  GMLS  to  the  fire  con- 
trol systems.  (SE1) 

For  certain  ships  in  the  class,  the  program  will  provide  solu- 
tions and  control  for  the  simultaneous  engagement  of  an  air  target  with 
SM-l(MR)  and  the  engagement  of  a surface  target  with  SSSM(ARM) . (SEl) 

The  TDS  program  has  provision  for  on-line  system  reconfigura- 
tion. (SEl , SE2 , SE3) 

The  TDS  program  is  modular.  (SE1,SE3) 

The  FCS  program  has  provision  for  a one-computer  reduced  capa- 
bility. (SE2) 

Prior  to  delivery  to  the  ship,  extensive  system  integration 
testing  was  conducted  at  the  test  facility  at  Mare  Island.  (IP3) 
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For  the  TDS,  there  was  a single  identifiable  responsible 
agent  for  module  design,  coding,  and  implementation. 

For  the  TDS,  the  maintenance  agent  (FCDSSA)  was  involved 
throughout  the  program  design,  development,  and  integration  phases 


(MS  2) 
(MS  3) 
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4.  DLGN-38  COMBAT  SYSTEM 


4.1  GENERAL  SYSTEM  DESCRIPTION 

DLGN-38  (USS  Virginia)  is  a multipurpose  all-digital  nuclear- 
powered  guided  missile  frigate  armed  with  the  Standard  Missile  (SM-1) 
Medium  Range  (MR)  Weapon  System.  It  is  the  first  of  a new  class  of  five 
ships  which  are  currently  authorized.  These  ships  will  have  missile  bat- 
teries and  lightweight  5"/54  gun  systems  fore  and  aft.  The  fully  inte- 
grated combat  system  will  utilize  a central  complex  of  AN/UYK-7  computers. 

The  mission  of  the  DLGN— 38  class  ship  is  to  operate  with  strike 
forces  and  to  screen  support  forces  and  convoys  against  submarine,  air, 
and  surface  threats.  Its  dominant  task  is  antiair  warfare  (AAW) . 

The  major  data  processing  subsystems  of  the  DLGN-38  Combat  Sys- 
tem are  the  Command  and  Control  System  (C&CS) , the  sensor  system  (which 
is  integrated  with  the  C&CS),  and  the  missile,  gun,  and  antisubmarine 
Weapon  Systems. 

4.1.1  Sensor  Interface  Data  System  (SIDS) 

The  SIDS  is  a real-time  data  processing  system  that  provides 
for  the  control  and  correlation  of  data  from  the  following  systems: 

1 . AN/SPS-48A  Radar  System 

This  three-dimensional,  electronically  stabilized  radar 
provides  primary  air  search  and  detection  capability  and 
moving  target  indication. 

2.  AN/SPS-40B  Radar  Syst  em 

This  two-dimensional  radar  provides  long-range  and  low- 
flying  target  detection,  clutter  rejection,  and  moving 
target  indication. 

3.  Automatic  Identification  Mk  XII  System  (AIMS) 

This  integrated  AN/UPX-12  interrogator  and  AN/APX-72  tran- 
sponder system  provides  decoded/encoded  information  for 
identification. 

4 . AN/SPS-55  Radar  System 

This  is  a surface  search  radar  providing  short-range  sur- 
face detection  and  navigation. 
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5.  AN/SQS-53A  Sonar  System 

This  is  a long-range  subsurface  active  and  passive  search, 
detection,  tracking,  and  classification  system. 

6.  Electronic  Warfare  (EW)  System 

The  best  available  production  EW  suite,  to  be  defined  by 
OPNAV,  will  be  used  initially. 

7 . AN/SPQ-9  Gun  Search  Radar  System 

This  radar  provides  secondary  surface  detection  and  navi- 
gation capability.  It  is  part  of  the  Mk  86  gun  fire  con- 
trol system. 

8.  AN/URN-20  Tactical  Air  Navigation  (TACAN)  System 

This  system  provides  relative  position  information  to  com- 
bat air  patrol,  surveillance  aircraft,  or  helicopters. 

4.1.2  Command  and  Control  System 

The  C&CS  is  a real-time  digital  data  processing  system  that 
provides  command  personnel  with  a summary  and  control  of  tactical  situa- 
tions existing  throughout  ownship  and  local  fleet  environments, 

4.1.3  Weapon  Systems 

The  following  are  the  major  data  processing  Weapon  Systems  on- 
board the  DLGN-38: 

1.  Mk  74  Mod  5 Missile  Fire  Control  System  (MFCS) /Weapon 
Direction  System  (WPS)  Mk  13 

This  is  a digital  processing  MFCS  that  provides  DLGN-38 
with  its  primary  surface-to-air  defensive  capability. 

2 . Mk  86  Mod  5 Gun  Fire  Control  System  (GFCS) 

This  is  a digital  processing  GFCS  that  provides  control  of 
the  5"/54  caliber  gun  during  air,  surface,  and  shore  en- 
gagements and  provides  the  MFCS  with  a third  radar/CW  il- 
luminator tracking  channel  capability. 

3.  Mk  116  Mod  1 Underwater  Fire  Control  System  (UFCS) 

Integrated  digital  processing  UFCS  element  of  the  anti- 
submarine warfare  (ASW)  system. 
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4.1.4  Supporting  Systems 

In  addition  to  the  preceding  data  processing  systems,  the 
DLGN-38  Combat  System  also  includes  the  following  supporting  systems: 

1 • Launching  System 

Mk  26  Guided  Missile  Launching  System  (GMLS) 

Two  self-contained  automatic  launching  systems  each  capa- 
ble of  stowing  and  handling  a mixed  load  of  SM-l(MR)  and 
ASROC. 

Mk  32  Mod  7 Torpedo  Tube 

Two  trainable  deck— mounted  tubes  each  consisting  of  three 
independently  operated  barrels  used  to  stow  and  launch 
Mk  46  Mod  1 torpedoes. 

Mk  45  Mod  0 5n/54  Caliber  Lightweight  Gun  Mount 

Two  shielded,  single-barrel,  automatic-fire,  dual-purpose, 
lightweight,  unmanned  gun  mounts  capable  of  local  or  re- 
mote control. 

2 . Communication  System 

Three  digital  links  (4A,  11,  and  14)  and  a variety  of 
voice  communications  equipment  permitting  communications 
with  other  elements  of  an  operating  task  force. 

3.  Display  System 

Display  of  radar  data  as  well  as  computer-generated  infor- 
mation accomplished  via  the  UYA— 4 general-purpose  display 
system. 

4.1.5  Acquisition  History 


The  DLGN-38  represents  the  Navy's  most  advanced  digitally 
automated  combat  system  at  the  present  time.  The  latest  generation  com- 
puters and  displays  are  used  throughout  the  system. 

The  DLGN-38  commenced  Concept  Formulation/Contract  Definition 
in  February  1968.  The  specifications  for  building  Nuclear  Guided  Mis- 
sile Frigate  DLGN-38,  contract  drawings,  and  the  Combat  System  Design 
Data  Document  (CSD3)  were  approved  on  21  November  1969.  During  the 
same  period,  the  DLGN-38  Ship  Acquisition  Project  Manager  (SHAPM)  de- 
veloped plans  for  the  overall  ship  procurement,  financial  management, 
configuration  control,  procurement  of  Government-Furnished  Equipment/ 


4-3 


THE  JOHNS  HOPKINS  UNIVERSITY 

APPLIED  PHYSICS  LABORATORY 

laurel,  Maryland 


Each  AN/UYK-7  used  in  a data  processing  system  consists  of  a 
cabinet  housing  seven  modules.  One  of  the  modules  will  always  be  the 
power  supply  (P/S) . The  other  modules  are  the  Input/Output  Controller 
(IOC),  Input/Output  Adapter  (IOA) , the  Central  Processor  Unit  (CPU), 
and  the  Memory  Units  (MU) . A maximum  of  one  CPU  and  one  IOC  can  be 
housed  in  each  cabinet.  Either  or  both  the  CPU  and  the  IOC  may  be  re- 
placed by  MU's.  If  the  IOC  module  is  replaced  by  an  MU,  then  the  IOA 
is  no  longer  necessary  and  will  be  replaced  by  a dummy  module.  If  there 
is  no  CPU  module  in  a given  AN/UYK-7 , it  is  considered  an  expanded  mem- 
ory  frame,  rather  than  a computer.  Any  unused  module  slot  shall  contain 
a dummy  module. 

The  CPU  contains  the  control  circuitry,  arithmetic  registers, 
arithmetic  timing,  and  control  circuitry  necessary  to  process  alphanu- 
meric information.  Features  of  the  unit  include  a repertoire  of  130 
instructions;  a set  of  privileged  instructions  for  the  interrupt  state; 
a nondestructive  readout  memory;  multiple  base  and  index  register  sets 
for  interrupt  and  task  states;  indirect  addressing;  variable  length 
character  addressing;  nonassigned  instruction  trap;  and  memory  read  or 
write  lockout  or  both.  It  is  capable  of  single  precision  fixed-point 
arithmetic,  double  precision  fixed-point  add,  subtract,  compare,  test, 
and  double  word  enter  and  store,  and  floating  point  arithmetic. 

The  main  memory  is  composed  of  lithium  ferrite  core  arrays  or 
stacks  having  a read-restore  time  of  1.5  ys.  Four  stacks,  each  contain- 
ing 4,096  32  bit  words,  are  assembled  on  a chassis  to  form  a 16,384 
32  bit  word  unit.  Each  unit  communicates  with  the  CPU  and  IOC's  over 
separate  memory  buses  connected  to  a chassis.  Eight  interfacing  paths 
(one  bus  and  one  port  for  each  path),  allowing  access  to  memory,  are 
provided  in  a 16  word  module  for  communication  with  other  modules. 
Separate  paths  are  used  by  the  processor  for  storing  and  receiving  data 
and  for  extracting  instructions  from  storage.  The  interfaces  are 
served  in  a priority  order  if  simultaneous  requests  are  presented.  The 
order  or  priority  is  fixed  at  the  time  the  interconnecting  bus  harness 
is  manufactured.  An  AN/UYK-7  computer  complex  may  contain  up  to  16  MU's, 
providing  a maximum  of  262,144  32  bit  words  of  memory.  Optional  inter- 
leaved addressing  between  two  MU's  is  possible.  This  technique  requires 
the  designation  of  each  MU  to  contain  only  even  or  odd  addresses  so  that 
two  requesting  devices,  such  as  one  or  more  processor  or  IOC,  can  make 
two  accesses  (retrieve  or  store)  to  two  blocks  of  information  with  each 
memory  cycle.  This  can  result  in  a reduction  in  time  of  as  much  as  50%. 

The  IOC  controls  information  transfer  to  and  from  peripheral 
equipment.  Signals  are  transferred  through  the  I/O  adapter  unit.  The 
IOC  uses  two  types  of  registers  to  interface  other  units  of  the  com- 
puter system,  the  control  interface  register  (CIR) , which  enables  com- 
munication with  the  CPU's,  and  the  data  interface  register  (DIR),  used 
for  communicating  with  memory  and  an  I/O  adapter.  The  IOC  contains  a 
repertoire  of  15  instructions  executable  as  a part  of  a CPU-associated 
command  chain  or  an  I/O  function  associated  chain,  or  both. 
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The  IOA  adapts  input  and  output  data  and  controls  signal  volt- 
ages  to  the  voltage  requirements  of  the  computer.  It  contains  drivers 
and  receivers  for  up  to  16  I/O  channels. 

The  P/S  unit  converts  primary  input  power  to  generate  regu- 
lated -90  V power  which  is  required  by  the  DC/DC  converters  contained  in 
each  unit.  It  also  furnishes  regulated  voltages  for  the  maintenance  con- 
sole and  operator’s  panel. 

Unused  positions  in  a main  cabinet  are  wired  for  power  and 
must  be  filled  with  a dummy  unit  if  not  used  by  one  of  the  unit  types 
listed  above. 

The  AN/UYK-7  Computer  Logic  Unit  Test  Sets  are  located  in  the 
computer  room  on  top  of  their  respective  computers.  These  consoles  pro- 
vide the  means  of  locally  controlling  the  computer  for  program  loading, 
program  debugging,  and  testing/maintenance  purposes. 

The  AN/UYK-7  Computer  Control  Units  are  located  in  the  CIC 
adjacent  to  the  monitor  and  control  console.  The  units  provide  a 
limited  means  for  remote  operator  control  of  computers. 

The  various  features  of  the  AN/UYK-7  data  processor,  such  as 
memory  busing  etc. , are  described  in  the  following  paragraphs.  With  all 
the  capabilities  of  the  AN/UYK-7,  there  are  several  interconnection  re- 
strictions on  communication  between  computers  which  greatly  influenced 
the  design  of  the  data  processing  complexes.  The  CPU,  for  example,  is 
capable  of  controlling  a maximum  of  four  IOC’s.  The  IOC  module,  in 
turn,  may  be  controlled  by  no  more  than  three  CPU’s.  Other  limitations 
are  listed  below: 

1*  A maximum  of  eight  accesses,  via  memory  buses,  may  be  made 
per  MU. 

2.  A maximum  of  16  memory  units  are  addressable  by  each  CPU 
and  each  IOC. 

3.  Each  CPU  can  have  two  accesses  (Instruction  and  Operand) 
and  each  IOC  requires  one  access  to  memory  units  via  mem- 
ory buses.  A CPU  can  access  a memory  unit  with  either  an 
Instruction  or  Operand  bus  only  when  the  system  design  so 
dictates . 

4.  A maximum  of  11  memory  buses  may  be  routed  between 
adjacent  frames. 

5.  A maximum  of  five  frames  may  be  interconnected. 

6.  A maximum  of  eight  memory  buses  may  be  terminated  in  any 
one  frame. 
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4.2.2  Peripheral  Characteristics  and  Selection  Criteria 

In  addition  to  the  computers,  the  system  is  supported  by  the 
following  peripheral  equipment: 

1 . Four  I/O  Consoles,  OJ-172 (V) /UYK 

The  I/O  Data  Exchange  Auxiliary  Console  (DEAC)  provides  the 
data  processors  of  the  DLGN-38  Class  ships  with  a collec- 
tion of  I/O  devices,  grouped  into  a single  cabinet  and  un- 
der a single  controller.  Each  DEAC  contains  two  magnetic 
tape  units,  a paper  tape  reader,  a paper  tape  punch,  and  a 
keyboard/printer . 

The  DEAC  is  capable  of  both  on-line  and  off-line  operation. 
On-line  operations , performed  under  computer  control , in- 
clude reading  data  into  the  computer  and  writing  data  from 
the  computer  using  the  various  recording  media  provided. 

The  read  and  write  functions  need  not  be  accomplished  with 
the  same  recording  medium.  Teletype  communications  are 
also  an  on-line  function.  Off-line  operations,  that  is  op- 
erations performed  without  computer  control,  include  the 
using  of  the  paper  tape  punch  or  keyboard  to  write  on  paper 
and/or  paper  tape.  The  magnetic  tape  unit  and  teletype  in- 
terface unit,  capable  of  only  on-line  operation,  can  be 
operated  while  the  remaining  equipment  is  off-line. 

2 . RD-281 (V) /UYK  (Mod)  Mass  Memory 

The  RD-281 (V) /UYK  (Mod)  Mass  Memory  is  a disk  file  provid- 
ing the  function  of  auxiliary  store  for  the  DLGN-38  data 
processing  element.  The  disk  file  is  capable  of  reading 
data  stored  on  the  magnetic  disk  into  the  computer  or  writ- 
ing data  from  the  computer  onto  the  magnetic  disk. 

3 . C&C  Signal  Data  Converter 

Two  identical  C&C  Signal  Data  Converters  perform  conver- 
sion for  the  various  signals  aboard  the  DLGN-38,  including 
D/D,  A/D,  D/A,  synchro-to-digital , and  digital-to-synchro . 

4.  IOC,  OA-7 984 (V) /UYK 

This  unit  interfaces  with  the  C&CS  computers.  The  console 
contains  a keyboard,  printer,  paper  tape  reader,  and  paper 
tape  punch  and  is  used  to  provide  a hard  copy  of  naviga- 
tion data  received  via  the  Navy  Navigation  Satellite  Sys- 
tem. In  addition,  the  keyboard  will  be  used  to  provide 
navigation  inputs  to  the  C&CS  computers. 
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5.  Combat  System  Monitor  and  Control  Group,  OJ-2QO/UYA-4 (V) , 

The  console  is  a Computer  Data  Terminal  (CDT)  type  device 
with  a CRT  display  mounted  on  a duplex/multiplex  module. 
The  CDT/CRT  display  device  is  capable  of  operating  in 
either  a dark  or  bright  environment  and  provides  a textual 
display.  The  duplexer  part  of  the  duplex/multiplex  module 
allows  two  computer  I/O  channels  to  communicate  with  the 
CDT/CRT  display.  The  multiplexer  part  provides  the  capa- 
bility for  up  to  eight  CDT/CRT  type  devices  to  communicate 
with  two  computers  via  the  multiplexer. 

6.  Digital  Data  Switching  Group  (DDSG)  , M/UYA-14 

The  DDSG  contains  32  T-bar  relays  configured  on  the  DLGN- 
38  Class  ship  to  provide  16  1 x 2 switching  elements. 

These  elements  are  used  to  reconfigure  C&C/SIDS,  I/O  chan- 
nel interfaces.  The  switching  is  controlled  manually  from 
either  the  remote  control  panel  located  in  CIC  or  from  the 
local  control  panel  mounted  on  the  DDSG  cabinet. 

7-  Digital  Fire  Control  Switchboard  (DFC  Swbd) 

The  DFC  switchboard  contains  T— bar  relays  in  each  of  its 
two  sections.  It  is  used  to  reconfigure  weapon  computer 
I/O  channel  interfaces.  The  switching  is  controlled  manu- 
ally either  from  a remote  control  panel  located  in  CIC  or 
at  the  switchboard. 

8.  Universal  Data  Entry  Keyset,  MX-3195 (V) /USQ-20 

This  unit  is  used  for  entering  aircraft  data,  communica- 
tions (Link  11)  broadcast  modes,  and  navigation  data  into 
the  C&CS  computer.  The  keyset  is  located  in  CIC  and  will 
only  be  used  when  operators  cannot  enter  data  from  their 
consoles  because  of  overloading.  The  keyset  is  also  used 
in  the  casualty  mode  if  the  display  module  controlling  the 
console  entries  becomes  inoperative. 

The  selection  of  the  above  equipment  is  based  upon  the  follow- 
ing criteria: 


1.  Standardization  of  data  processing  equipment  to  reduce 
spare  parts  logistics  and  to  reduce  operation  and  mainte- 
nance complexity  (with  corresponding  reduction  in  person- 
nel training  requirements). 

2.  Growth  potential  of  the  data  processing  system,  permitting 
the  utilization  of  more  advanced  technology  in  other  ele- 
ments of  the  total  combat  system. 
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3.  Flexibility  of  operation  required  for  casualty  recovery, 
on“line  an<3  off-line  testing,  maintenance,  and  operator 
training. 

4.  Simplification  of  the  man/machine  interface  and  the  inter- 
face between  computers  and  computer-controlled  equipment. 

4.2.3  Functional  Allocation  among  Computers 

The  computer  system  aboard  the  DLGN-38  is  functionally  organ- 
ized into  four  separate  processing  complexes: 

1.  Command  and  Control  System/Sensor  Interface  Data  System 

2.  Mk  74  Missile  Fire  Control  System 

3.  Mk  86  Gun  Fire  Control  System 

4.  Mk  116  Underwater  Fire  Control  System 

the  flexibility  of  the  UYK— 7 , the  DLGN— 38  has  incorporated 
both  the  unit  computer  concept  and  the  multiprocess /memory— sharing  con- 
figuration into  the  design  of  the  combat  system.  Each  of  the  Mk  74, 

Mk  86,  and  Mk  116  systems  is  supported  by  a single  bay  UYK-7  computer 
(with  1 CPU,  3 MU’s,  and  1 IOC).  Conversely,  the  C&CS  and  SIDS  systems 
are  supported  by  a four-bay  computer  complex.  This  complex  utilizes 
the  multiprocessing  capability  of  the  UYK-7.  Multiprocessing  is  per- 
formed within  the  two  bays  dedicated  to  the  C&CS.  The  C&CS  computers 
can  access  the  three  memory  units  contained  in  the  SIDS  main-frame. 

4.2.4  Interrelation  among  Computers  and  Sensor/Weapon  Interfaces 

The  use  of  general-purpose  machines,  redundant  equipment,  and 
multiple  data  flowpaths  permits  the  retention  of  operational  readiness 
even  under  a high  level  of  casualty.  Therefore,  the  system  is  designed 
to  recover  from  casualties  ranging  from  the  loss  of  a single  peripheral 
device  to  the  loss  of  a whole  bay.  The  number  of  reconfiguration  al- 
ternatives is  too  great  to  address  in  this  appendix.  For  more  informa- 
tion on  casualty  reconfiguration,  it  is  suggested  the  reader  refer  to 
Section  C of  the  DLGN-38  Integrated  Combat  System  Design  Data  Document, 
NAVSHIPS  0967-014-1040. 


4.3  COMPUTER  PROGRAM  ARCHITECTURE 

The  following  sections  discuss  the  software  architecture  for 
the  DLGN-38  Combat  System.  A discussion  is  given  for  the  C&CS/SIDS 
computer  complex,  and  the  Mk  74  MFCS  has  been  selected  as  an  example  of 
the  many  Weapon  System  programs. 
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4.3.1  Command  and  Control  System/Sensor  Interface  Data  System  Com- 
puter Programs 

The  DLGN-38  C&CS/SIDS  computer  programs  are  designed  to  oper- 
ate in  a four-bay  AN/UYK-7  complex  consisting  of  13  memory  units  (212,992 
words).  The  modular  configuration  for  both  the  C&CS  and  SIDS  programs 
may  be  loaded  by  the  Monitor  Control  Console  (MCC)  Operator  at  the  0J- 
200  console.  The  operator  selects  from  a predetermined  list  of  configu- 
rations, each  of  which  are  based  on  a required  level  of  readiness.  In 
the  event  that  a modular  configuration  is  currently  loaded  and  addi- 
tional capabilities  are  desired,  the  operator,  via  Dynamic  System  Re- 
configuration (DSR) , can  select  individual  modules  which  provide  the 
required  capability  to  be  loaded  from  the  RD-281  disk  memory,  or  the 
OJ-172  as  a backup. 

4.3.2  C&CS/SIDS  Program  Architectural  Structure 

Both  the  C&CS  and  SIDS  programs  are  divided  into  a series  of 
identifiable  subprograms  called  "modules."  These  modules  are  grouped 
in  a variety  of  configurations  to  satisfy  the  various  levels  of  readi- 
ness conditions  of  the  DLGN-38.  Each  module  falls  into  one  of  the  four 
categories  listed  below: 

1.  Resident  Control  module  — requires  full-time  residency  in 
core  (e.g.,  Executive). 

2.  Base  module  — provides  required  support  function  in  all 
configurations  (e.g.,  Display). 

3.  Configuration  Alternative  module  — provides  warfare  and 
operational  capability  to  support  mission  requirements 
(e.g.,  Threat  Evaluation). 

4.  Transient  module  — provides  selected  capability  that  can 
be  utilized  and  then  deleted  or  replaced  with  another 
capability  as  needed  (e.g.,  Training). 

A configuration  selected  for  a condition  of  readiness  will  consist  of 
all  Resident  Control  and  Base  modules  and  the  selection  of  appropriate 
Configuration  Alternative  modules.  Transient  modules  will  be  loaded 
separately  when  required. 

4.3.3  C&CS/SIDS  Executive  Programs 

Both  the  C&CS  and  SIDS  programs  use  the  Common  Program  Execu- 
tive designed  by  Univac.  This  executive  can  operate  in  a multiprocessor 
mode  (C&CS)  or  can  be  adapted  to  a single  processor  (SIDS). 
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4.3.4  C&CS/ SIDS  Equipment  Interfaces  and  Module  Functions 

Communication  with  other  systems  is  accomplished  through  a 
series  of  interface  modules.  Each  of  these  modules  is  designed  to  send 
and  receive  data  from  another  system  in  a form  that  is  acceptable  to 
that  system. 

Table  4-2  gives  a brief  description  of  each  module  in  the  C&CS 
program  with  the  projected  (resident  plus  nonresident)  core  requirements 
of  each  module.  Table  4-3  gives  a brief  description  of  each  module  in 
the  SIDS  program  with  representative  core  requirements  of  each. 

4.3.5  Mk  74  Mod  5/WDS  Mk  13  Mod  0 — Missile  Fire  Control  System 

Computer  Program 

The  MFCS  program  resides  in  a single  UYK-7  computer  and  per- 
forms two  basic  functions:  FCS  radar  control  and  WDS  target  scheduling. 

Both  functions  are  performed  on  an  almost  independent  basis  as  two  com- 
puter programs. 

4.3.6  Missile  Fire  Control  System  Program  Architectural  Structure 

Of  the  two  basic  functions,  FCS  radar  control  and  WDS  target 
scheduling,  the  radar  control  is  the  more  time  critical.  Consequently, 
the  radar  control  program  is  executed  in  the  Executive  state  of  the 
UYK-7,  while  the  WDS  program  is  executed  in  a "background"  sense  in  the 
Task  state  of  the  computer  during  unused  FCS  time. 

Each  program  is  controlled  by  its  own  Executive,  with  a clock- 
interrupt  scheme  to  monitor  and  control  the  FCS  Executive  program. 

Each  Executive  calls  upon  subprograms,  or  modules,  to  perform  desired 
functions,  and  all  I/O  is  performed  by  common  routines  in  the  Executive 
state  of  the  computer. 

The  overall  program  is  modular  in  the  sense  that  series  of 
closed  routines,  called  subprograms,  are  grouped  together  in  modules  to 
perform  basic  identifiable  functions.  Six  modules  contain  29  subpro- 
grams . 

4.3.7  Missile  Fire  Control  System  Executive  Program 

Processing  of  tasks  within  the  radar  control  program  is  regu- 
lated by  a clock- interrupt-driven  Executive  program.  All  required  FCS 
functions  are  performed  within  each  repeated  32  ms  time  frame,  with  all 
unused  time  provided  for  Task  state  execution  of  WDS  functions.  All  WDS 
processing  is  performed  within  a 2 second  period. 
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TABLE  4-2 

C&CS  PROGRAM  MODULE  DESCRIPTIONS 


Module/ 

Segment 

Group 

Module  (segment) 
Name 

Brief  Description 

Core 

Alloca- 

tion 

Common  Control 

Executive  for  C&CS  program. 

4,280 

Common  Peripheral 

Permits  communication  with  OJ-172  paper  tape,  magnetic 
tape  units,  teletype,  etc. 

5,406 

Resident 

Control 

Common  System 

Regional  and  global  data  base  for  C&CS  track  data, 
weapon  data  and  status,  etc. 

15,390 

Dynamic 

Reconfiguration 

Provides  for  reconfiguration  of  the  on-line  program. 

5,437 

System  Control 

Supports  use  of  MCC  for  controlling  system  configuration 
and  provides  for  monitoring  of  overall  combat  system 
performance  — provides  alerts. 

18,170 

System  Loader 

Loads  the  program  in  core  from  tape  or  disk. 

91 

Debug 

Provides  for  computer  program  problem  resolution. 

11,300 

Display 

Provides  for  OJ-194  console  PPI  symbology,  lines,  etc., 
data  read-outs  (remote  and  attached  to  console).  In- 
terrogates consoles  and  passes  data  to  responsible 
modules . 

19,863 

Base 

Tracking 

Provides  for  manual  tracking,  correlation  of  C&CS  tracks 
with  EW  data,  fire  control  system  data,  and  remote  Link  11 
tracks  with  local  tracks. 

11,916 

Identification 

Provides  for  assignment  of  an  ID  (friend,  hostile,  etc), 
category  (air,  surface,  subsurface),  and  classification 
(cruiser,  fast  patrol  boat,  etc.). 

2,765 

Signal  Data  Con- 
verter 

Interrogates  Signal  Data  Converter  Mk  72  to  obtain  ship 
parameter  data  (course,  speed,  roll,  pitch),  logical 
status  from  external  systems,  etc. 

3,389 
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TABLE  4-2  (Cont'd) 


Module/ 

Segment 

Group 

Module  (segment) 
Name 

Brief  Description 

Core 

Alloca- 

tion 

Navigation 

Provides  for  entry  of  ship  position  and  accommodates  (dead 
reckoning)  motion  of  ship  geographically  between  fixes. 

8,850 

Base 

(Cont'd) 

Link  11 

The  intership  data  link  that  passes  track  data,  weapon 
status,  force  orders,  etc.  Also  used  between  ships  and 
P-3  aircraft. 

14,313 

Surface  Operations 
(surface  maneuver- 
ing) 

Provides  for  calculations  of  point-to-point  ship  maneu- 
vers, collision  avoidance  alerts,  closest  point  of  ap- 
proach calculations,  etc. 

11,044 

Gun  Interface 

Provides  interface  with  Mk  86  gun  fire  control  system. 

4,296 

Configu- 

ration 

Missile  Interface 

Provides  interface  with  Mk  74  MFCS  and  WDS  Mk  13. 

5,608 

Alterna- 

ASW Interface 

Provides  interface  with  Mk  116  Mod  1 UFCS 

6,226 

tive 

SIDS  Interface 

Provides  interface  with  sensor  interface  data  system  via 
shared  memory  — supports  BVP  and  RVP  operator  modes. 

10,576 

Threat  Evaluation 

Provides  a relative  threat  ranking  of  system  tracks,  both 
air  and  surface,  to  facilitate  correct  order  of  engage- 
ment . 

2,611 

Weapon  Assignment 

Provides  for  response  to  force  or  locally  ordered  engage- 
ments, selects  targets  in  order  of  engagement  priority 
and  weapon  availability. 

12,778 

Height  — Size 

Provides  for  interface  with  SPS-48  Radar  Set  Control  (RSC) , 
allows  entry  of  track  height,  depth,  and  size  either  at 
the  RSC  (height  only)  or  via  entries  at  console  modes. 

1,941 

ASW  Management 

Provides  for  operator  controls  and  displays  at  the  ASW  con- 
sole mode  and  surf ace/subsurface  surveillance  coordinators 
mode  to  control  sonar  search,  classify  contracts,  etc. 
Convergence  Zone  Calculation. 

5,669 
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TABLE  4-2  (Cont'd) 


Module/ 

Segment 

Group 

Module  (segment) 
Name 

Brief  Description 

Core 

Alloca- 

tion 

Configu- 
ration 
Alterna- 
tive 
(Cont ? d) 

Sonar  Processing 

Provides  for  direct  input  of  SQS-53A  sonar  data  into  C&CS 
when  the  Mk  116  UFCS  is  off-line.  Tracks  sonar  targets 
and  presents  displays  for  use  in  urgent  attack  using  over 
the  side  torpedoes. 

3,616 

Air  Control  (in- 
tercept vectoring) 

Provides  for  calculation  of  intercept  geometries  and  all 
actions  associated  with  the  control  of  interceptor,  ASW 
fixed-wing  and  helicopter  aircraft.  Support  of  LAMPS 
Mk  1 is  in  ASW  management  module  (sonobuoy  management). 

10,064 

Link  4A 

Provides  for  interconnection  of  the  air  control  function 
with  Link  4A  orders,  status,  and  responses. 

9,022 

ASW  Management 
(sonobuoy  manage- 
ment) 

Provides  support  for  LAMPS  Mk  1/fixed-wing  ASW  sonobuoy 
data,  computation  of  hyperbolic  and  comparative  LOFAR 
fixes . 

886 

Link  14 

Provides  for  a one-way  teletype  link  to  broadcast 
track  and  engagement  data  to  non-TDS  ships;  only  one  ship 
per  force  broadcasts. 

3,781 

Transient 

Satellite  Naviga- 
tion 

Provides  for  calculation  of  ship  position  using  SRB-9 
satellite  data. 

7,579 

Electronic  Warfare 

Provides  only  a basic  capability  for  manual  entry  of  EW 
data,  bearing  lines,  and  EW  fixes. 

3,309 

Test  Control 

Provides  for  system  testing  using  combat  system  operabil- 
ity , alignment,  and  interface  tests.  Provides  capability 
to  call  in  Programmed  Operational  and  Functional  Appraisal 
(POFA)  programs  to  test  suspected  equipment  faults  while 
the  Operational  Program  is  still  on-line. 

9,826 

Training 

Provides  for  control  of  SM-441  video  simulator,  which  pro- 
vides targets  for  local  training  and  passes  targets  to 
other  ships  via  Link  11  for  force  training. 

7,625 

THE  JOHNS  HOPKINS  UNIVERSITY 

APPLIED  PHYSICS  LABORATORY 

LAUREL,  MARYLAND 


4-16 


TABLE  4-2  (Cont'd) 


Module/ 

Segment 

Group 

Module  (segment) 
Name 

Brief  Description 

Core 

Alloca- 

tion 

Transient 

Data  Extraction 

Provides  a capability  to  extract  a continuous  summary 

5,925 

(Cont f d) 

of  events,  buffer  traffic  between  systems  link  data, 

etc.  for  later  reduction  and  analysis. 

DX  Control 

Provides  control  over  data  extraction  (DX)  process 

20,105 

(Tactical  and  Continuous  System  Operational  Test) . 
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TABLE  4-3 

SIDS  PROGRAM  MODULE  DESCRIPTION 


Module 

Group 

Module  Name 

Brief  Description 

Core 

Alloca- 

tion 

Resident 

Control 

Command  Control 
Common  System 
System  Loader 
Debug 

See  Table  4-2. 

3,600 

8,124 

4,507 

5,114 

C&CS  Interface 

Provides  interfaces  with  C&CS 
via  shared  memory 

564 

Sensor  Data 
Management 

Provides  for  the  control  and 
coordination  of  data  received 
from  on-board  sensor 

11,226 

Base 

Beacon  Video 
Processor 

Provides  for  the  operation  and 
control  of  the  BVP 

5,523 

Radar  Video 
Processor 

Provides  for  the  operation  and 
control  of  the  RVP 

8,525 

Common  Peripheral 

5,278 

Transient 

Data  Extraction 

See  Table  4-2 

7,444 

DX  Control 

1,613 

4.3.8  Missile  Fire  Control  System  Equipment  Interfaces 

functions  are  called  upon  as  needed,  using  common  rou- 
tines, to  interface  with  the  Naval  Tactical  Data  System  (NTDS),  Signal 
Data  Converters,  the  gun  fire  control  computer,  displays,  two  Mk  26 
launchers,  and  two  launching  system  consoles. 

1.  NTDS  Interface 


NTDS  target  designations,  engagement  orders,  and  schedul- 
ing data  are  exchanged  using  a single  I/O  channel  from  a 
C&CS  computer  to  the  MFCS  computer  (MFCC) . 
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2 . Signal  Data  Converter 

Two  Signal  Data  Converters  are  used  to  exchange  director 
and  radar  feedback  and  commands  with  the  MFCC.  One  Sig- 
nal Data  Converter  and  MFCC  channel  are  used  for  each 
director. 

3.  Launching  System  Module  Console  (LSMC) 

Two  LSMCfs  are  interfaced  with  the  MFCC  using  a single 
I/O  channel  to  display  launcher  status  and  to  transfer 
LSMC  orders  to  the  MFCC. 

4 . Gun  Fire  Control  Computer  (GFCC) 

An  intercomputer  I/O  channel  is  used  to  exchange  data 
between  the  missile  system  and  the  gun  system.  This  al- 
lows the  use  of  the  gun  director  for  missiles  and  inter- 
director designations  between  the  gun  and  missile  systems. 

5 . Pulse  Amplifier/Symbol  Generator  (PA/SG) 

A single  MFCC  I/O  channel  is  provided  to  drive  UYA-4 
console  displays  and  to  allow  manual  inputs  for  NTDS 
casualty  operation.  This  channel  may  be  switch-select- 
able  as  an  input  to  the  PA/SG. 

6 . Mk  26  Launcher 

The  MFCC  interfaces  directly  with  each  of  the  two  Mk  26 
missile  launchers,  using  one  I/O  channel  each,  to  ex- 
change launcher  orders  and  repeat-back  data. 

4.3.9  Missile  Fire  Control  System  Module  Functions 

The  primary  functions  of  the  MFCS  modules  and  their  approxi- 
mate core  allocations  are  given  in  Table  4-4. 


4.4  SOFTWARE  DEFINITION,  DESIGN,  AND  IMPLEMENTATION 

The  DLGN-38  commenced  Concept  Formulation/Contract  Definition 
in  February  1968.  During  this  process  detailed  studies  and  designs 
were  carried  out,  leading  to  the  completion  of  ship  contract  specifica- 
tions and  drawings,  and  the  guidance  document  describing  the  combat 
system  baseline  design.  The  specifications  for  building  Nuclear  Guided 
Missile  Frigate  DLGN-38  and  contract  drawings  and  the  Combat  System  De- 
sign Data  Document  (CSD^)  were  approved  on  21  November  1969. 
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TABLE  4-4 

MISSILE  FIRE  CONTROL  SYSTEM  MODULE  FUNCTIONS 


Module 

Brief  Description 

Core 

Allocation 

Executive 

Contains  initialization,  interrupt 
controller,  Task  controller,  and 
I/O. 

4,760 

FCS 

Determines  radar  modes,  frequency 
selection,  weapons  orders,  and 
tracking. 

8,690 

WDS  Communication 

Controls  launcher  and  C&CS  communica- 
tion. Controls  consoles  in  casualty. 

6,685 

WDS  Scheduling 

Determines  target  engageability , tar- 
get scheduling,  launching  system 
assignment,  designation  update. 

7,887 

Operability 

Performs  system  monitoring  and  Daily 
System  Operability  Tests. 

4,012 

Common 

Contains  common  subroutines. 

1,085 

The  program  production  phase  consists  of  the  determination  of 
requirements,  the  development  of  program  specifications,  and  the  produc- 
tion of  the  computer  programs.  This  first  step  takes  place  at  the  ven- 
dor or  program  maintenance  agency  plant  and  terminates  when  the  programs 
are  validated  and  delivered  to  the  Shore  Systems  Integration  Site  (SSIS) 
for  combat  system  integration  testing. 

The  following  baselines  were  established  to  serve  as  techni- 
cal references  for  the  design  and  implementation  stages. 

1.  Functional  Baseline 


The  Functional  Baseline  was  established  through  definitions 
and  descriptions  of  the  following  system  documents: 

a.  NTDS  Tactical  Operational  Requirements  for  DLGN-38. 

b.  DLGN-38  Integrated  Combat  System  Design  Data  Docu- 
ment, NAVSHIPS  0967-014-1040. 

c.  Interface  Design  Specifications. 
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2 . Allocated  Baseline 

The  Combat  System  Allocated  Baseline  was  established  when 
the  Navy  accepted  the  Computer  Program  Performance  Speci- 
fications for  each  subsystem. 

3.  Product  Baseline 


The  Combat  System  Product  Baseline  is  defined  by  the  Navy- 
approved  Program  Design  Specification,  Test  Plans  and  Pro- 
cedures, Operating  Procedures /manuals , and  tapes  and  list- 
ings. The  Product  Baseline  will  provide  the  information 
necessary  for  procurement,  integration,  and  acceptance  of 
combat  system  computer  programs  for  subsequent  ships  of 
the  DLGN-38  Class. 


4.5  SOFTWARE  VALIDATION  AND  INTEGRATION 

Each  subsystem  computer  program  is  subjected  to  checks  at 
various  shore-based  test  sites  until  final  acceptance  testing  is  con- 
ducted on  board  the  ship.  The  objective  is  to  produce  a mission- 
capable  ship  and  to  demonstrate  this  capability  during  final  contract 
trials  (FCT) . 

The  initial  integration  phase  includes  all  activities  at  the 
SSIS  wherein  the  programs,  upon  receipt,  are  placed  under  formal  con- 
figuration control.  These  programs  undergo  integration  and  testing  em- 
ploying the  SSIS  facility.  This  step  will  terminate  with  the  comple- 
tion of  integration  and  the  transfer  of  the  programs  from  the  SSIS  to 
the  ship/Fleet  Combat  Direction  System  Support  Activity  (FCDSSA) , Dam 
Neck  (DN). 


The  next  stage  of  the  overall  program  development  includes 
shipboard  testing  up  to  and  including  the  Operational  Program  Func- 
tional Checkout  (OPFCO).  During  this  time,  the  programs  will  be  under- 
going a continuing  series  of  tests  at  both  the  maintenance  facilities 
and  on  board  the  ship.  Prior  to  introduction  to  the  ship,  the  C&CS/ 

SIDS  programs  will  undergo  preliminary  acceptance  testing  at  FCDSSA(DN) . 
Other  subsystem  programs  will  undergo  preliminary  acceptance  tests  at 
SSIS  and  other  support  centers.  This  phase  is  terminated  by  the  formal 
acceptance  of  the  program  following  OPFCO. 


4.6  SOFTWARE  ACQUISITION  MANAGEMENT  ORGANIZATION  AND  METHODS 

The  complexity  of  the  DLGN-38  Class  combat  system  with  its 
several  component  computer  programs  dictates  the  establishment  of  a 
vigorous  management  scheme.  Overall  responsibility  for  the  procurement, 
design,  and  integration  of  the  DLGN-38  combat  system  is  vested  in  the 


4-20 


THE  JOHNS  HOPKINS  UNIVERSITY 

APPLIED  PHYSICS  LABORATORY 

LAUREL,  MARYLAND 

AAW  Ship  Acquisition  Project  Manager  (SHAPM,  PMS-378).  During  the 
period  February  1968  to  November  1969,  SHAPM  developed  plans  for  the 
overall  ship  procurement,  financial  management,  configuration  control, 
procurement  of  Government-Furnished  Equipment /Government-Furnished  In- 
formation, and  other  items  as  set  forth  in  the  Ship  Acquisition  Plan. 

The  Product  Baseline,  as  described  in  Section  4.4,  will  be 
used  in  the  acquisition  of  combat  system  software  for  subsequent  ships 
of  the  DLGN-38  Class. 

SHAPM  has  established  a management  organization  that  permits 
the  orderly  procurement  and  integration  of  all  elements  of  the  combat 
system.  Table  4-5  indicates  the  various  organizations  assigned  to  meet 
this  goal. 


TABLE  4-5 

SOFTWARE  MANAGEMENT  INFORMATION,  DLGN-38  CLASS 


C&CS/SIDS 

Mk  116  UFCS 

Mk  74  MFCS 

Mk  86  GFCS 

Program 

Manager 

NAVSEC 

NAVSEA 

NAVSEA 

NAVSEA 

System 

Contractor 

Univac 

NUC 

Raytheon 

Lockheed 

Type  Contract 

CPFF 

WR 

FP  & LOE 

LOE 

Program 

Status 

Ship  Testing 

Ship  Testing 

Ship  Testing 

Ship  Testing 

Maintenance 

Agent 

FCDSSA(DN) 

NUC 

NSWC  Dahlgren 

NSWC  Dahlgren 

Software 

Deliverables 

Operational  Program  and  Program  Documentation 

Validation 

Agent 

NAVSEC 

NAVSEA 

NAVSEA* 

NAVSEA 

Integration 

Agent 

Combat  System 

Integration  Manager 

*FCDSSA(DN)  assigned  as  SHAPM  agent  to  witness  and  report  to  SHAPM  on 
program  certification 

CPFF  = Cost  plus  fixed  fee 
WR  = Work  request 
FP  = Fixed  price 
LOE  = Level  of  effort 
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4.6.1  Management  Plan 

The  Integrated  Combat  System  Management  Plan  (ICSMP)  for  the 
DLGN-38  Class  is  derived  from  the  DLGN-38  Ship  Acquisition  Plan  and  from 
the  chartered  responsibility  for  acquisition  of  the  ship  by  the  SHAPM. 

The  ICSMP  provides  for  management  of  combat  system  integration  by  estab- 
lishing and  coordinating  the  schedules,  work  plans,  facility  require- 
ments, etc.  of  agencies  participating  in  development. 

The  document  is  the  parent  document  for  all  the  supporting 
Combat  System  Management  efforts  required.  The  tasks  of  this  document 
which  relate  to  tests  provide  the  guidance  for  the  overall  Combat  System 
Test  Plan  (CSTP)  which  has  as  its  end  purpose  the  demonstration  that  the 
combat  system  meets  all  requirements.  The  CSTP  was  contractually  invoked 
with  the  shipbuilder  by  Headquarters  Modification  Requisition  (HMR-144) 
forwarded  by  NAVSEA  ltr  PMS378/JJD  Ser  1195  dated  4 November  1974. 

Because  of  the  many  tasks  involved,  the  details  of  the  tasks 
are  developed  in  the  ICSMP,  showing  an  agency’s  responsibilities  and 
contributing  activities.  By  this  means  each  agency  can  determine  the 
impact  of  its  assignment  on  other  tasks  being  performed.  The  level  of 
tasks  identified  in  the  ICSMP  is  only  as  deep  as  major  assignments  to  in- 
dividual agencies.  Ship  Project  Directives  written  to  accomplish  these 
major  task  assignments  are  in  greater  detail  and  consist  of  line  items 
against  which  funds  will  be  allocated. 

4.6.2  Software  Configuration  Management 

The  development  of  the  DLGN-38  computer  programs  is  divided 
into  three  major  phases: 

Phase  I - Program  Production  and  Initial  Integration 

Phase  II  - Program  Integration  and  Shipboard  Delivery 

Phase  III  - Program  Maintenance 

The  management  and  control  of  configuration  is  facilitated 
through  the  establishment  of  baselines.  These  baselines  serve  as  tech- 
nical references  from  which  the  system  elements  may  evolve  to  eventu- 
ally become  operational  systems.  Since  MIL-STD-480  and  NAVMATINST 
4130. 1A  do  not  detail  the  configuration  control  of  computer  programs  to 
the  degree  necessary  for  DLGN-38  Class  combat  systems,  the  Software  Con- 
figuration Control  Procedures  manual,  NAVSEA  0900-LP-080-2010 , expands 
basic  terms  and  adds  new  terms  where  necessary.  The  four  baselines  are 
the  Functional  Baseline,  the  Allocated  Baseline,  the  Product  Baseline, 
and  the  Operational  Baseline. 
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The  primary  control  over  software  is  vested  in  the  Software 
Conf iguration  Control  Board  under  the  direction  of  FCDSSA(DN) . This 
board  exercises  its  control  through  a series  of  reviews  and  audits  as 
discussed  below: 

1.  Preliminary  Design  Review  (PDR) . The  conduct  of  program 
documentation  reviews  is  the  responsibility  of  the  Navy 
manager  tasked  with  the  individual  program  development. 

The  PDR  serves  as  a means  for  reaching  common  agreement 
between  the  Navy  and  the  development  contractor  on  the 
content  of  deliverable  documentation  as  specified  in  the 
Critical  Design  Review  (CDR) . Acceptance  of /or  correc- 
tions to  the  documentation  will  be  determined  during  the 
PDR.  PDR1 s are  scheduled  by  the  Subsystem  Managers  as  re- 
quired to  ensure  prompt  processing  of  action  items  and  to 
comply  with  formally  established  design  review  milestones. 

2.  Critical  Design  Review.  The  CDR  includes  a comprehensive 
review  of  the  individual  system  to  include  system  configu- 
ration, design  details,  and  tests  considered  critical  to 
ensure  satisfactory  compliance  with  performance  require- 
ments. The  CDR  is  conducted  on  an  incremental  basis 
rather  than  as  a single  CDR,  to  provide  progressive  re- 
views to  disperse  the  load  over  an  ex^en^ed  period  of  time; 
however,  a final  CDR  is  scheduled  to  provide  a last  over- 
view and  clearer  insight  into  program  technical  risks  asso- 
ciated with  each  Configuration  Item.  The  risk  discussions 
are  addressed  on  a cost  and  schedule  basis  in  addition  to 
the  technical  problems  involved. 

3.  Configuration  Inspections/Audits . Prior  to  beginning  cer- 
tification testing,  a team  designated  by  SHAPM  for  the  pur- 
pose of  conducting  configuration  inspections  shall  be 
formed.  This  team  shall  be  authorized  to  visit  the  devel- 
opment activity/maintenance  activity  of  each  Subsystem 
Manager  to  establish  the  pre-preliminary  Product  Baseline 
of  each  system  that  will  undergo  independent  formal  valida- 
tion testing  prior  to  Phase  I integration  at  SSIS.  This 
inspection  will  determine  the  following  data  for  use  in 
describing  the  baseline  system: 

a.  Documentation  status. 

b.  Current  status  of  programs  and  tentative  schedule  for 
validation  testing. 

c.  Configuration  control  procedures  currently  in  use  at 
the  particular  activity. 
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cL  Degree  of  Navy  control  of  current  Contract  Data  Require- 
ments List  items  (i.e.,  accepted  deliverables,  under  or 
not  under  configuration  control) . 

e.  Activity  responsible  for  documentat ion/sof tware  mainte- 
nance (if  contractor). 

4.  Preliminary  Product  Baseline  Configuration  Audit.  Upon 
completion  of  validation  testing  of  each  subsystem,  the 
Preliminary  Product  Baseline  configuration  audit  shall  be 
validated  to  ensure  that  the  developed  programs  performed 
as  specified  and  that  documents  have  essentially  been  com- 
pleted. At  this  time  the  documentation  and  software  con- 
figuration items  comprising  the  Preliminary  Product  Base- 
line will  be  placed  under  formal  configuration  control  and 
the  directives  of  the  Configuration  Control  Procedures 
Manual  will  be  instituted  for  all  subsequent  actions  af- 
fecting both  documentation  and  program  changes. 

5.  Final  Software  Audits.  The  final  audit  of  computer  pro- 
grams and  their  associated  documents  will  be  performed 
just  prior  to  the  final  delivery  of  updated  programs  and 
documents  by  all  activities  to  FCDSSA(DN) . This  audit 
shall  be  made  after  successful  completion  of  the  Opera- 
tional Performance  Functional  Checkout  (OPFCO)  and  shall 
result  in  establishment  of  the  Operational  Baseline.  This 
audit  will  assure  that  the  configuration  listing  for  all 
programs  is  correct  and  up-to-date  upon  commencement  of 
the  program  life  cycle  maintenance  phase.  All  program 
master  tapes,  noncompiled  patches,  and  verified  copies  of 
all  required  documentation  will  be  deposited  at  FCDSSA(DN) 
where  configurations  will  be  rigorously  controlled  and  re- 
ports of  status  issued  on  a periodic  basis.  Procedures 
for  acquisition  of  tapes  are  set  forth  in  the  Configura- 
tion Control  Procedures  Manual,  Section  4. 

4. 6. 2.1  Audit  Guidelines 

The  following  general  provisions  are  applied  to  audits; 

1«.  Audits  shall  be  kept  to  the  minimum  number  necessary  to 
provide  acceptable  visibility. 

2.  Demonstration  requirements,  including  where,  when,  and  the 
scope/degree  of  the  audit,  will  be  specified  in  detail  at 
the  time  of  scheduling. 

3.  Prior  to  establishment  of  the  Operational  Baseline,  the 
responsibility  for  scheduling  audits  will  reside  with  the 
Combat  System  Manager. 
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4.  After  the  operational  baseline  is  established  and  the  life 
cycle  maintenance  phase  is  instituted,  the  Commanding 
Officer  FCDSSA(DN)  will  be  responsible  for  scheduling 
audits  in  compliance  with  the  assigned  task  of  continued 
DLGN-38  combat  system  computer  program  configuration  con- 
trol . 

5.  Audits  will  be  scheduled  to  allow  the  activity  subject  to 
audit  30  calendar  days  in  which  to  prepare  for  the  for- 
mally stated  audit  requirements. 

4.7  OPERATIONAL  SOFTWARE  MAINTENANCE 

Phase  III  of  the  DLGN-38  combat  system  is  initiated  by  the  suc- 
cessful completion  of  0PFC0.  It  is  during  this  period  that  the  ship, 
with  its  combat  system,  is  turned  over  to  the  Operational  Fleet  Commander. 
This  marks  the  beginning  of  the  life-cycle  maintenance  phase  as  opposed 
to  the  life-cycle  production  phase.  Configuration  control  by  SHAPM  con- 
tinues until  Final  Contract  Trials  some  eight  months  after  0PFC0  at  the 
termination  of  Ship  Construction  Navy  (SCN)  funding. 

The  Operational  Baseline  is  a useful  configuration  control  de- 
vice for  this  phase.  NAVMATINST  4130. 1A,  paragraph  1-5. g,  states, 
"Baselines  will  be  established  at  those  points  in  a program  where  it  is 
necessary  to  define  a formal  departure  point  for  control  of  future 
changes  in  performance,  design,  production  and  related  technical  re- 
quirement" (Emphasis  added). 

Due  to  the  radical  shift  in  responsibility,  funding,  and  ac- 
counting for  software  in  shipboard  combat  systems  when  the  production 
phase  ends  and  the  ship  becomes  operational,  an  extension  of  the  Product 
Baseline  under  the  name  of  Operational  Baseline  is  established.  The 
combat  system  Operational  Baseline  will  be  established  upon  completion 
of  OPFCO  and  Navy  acceptance  of  all  shipboard  integrated  subsystem  pro- 
grams with  associated  hardware  items.  This  baseline  shall  provide  for 
the  development  and  shipyard  testing  of  subsequent  ships  of  the  class 
as  a Product  Baseline.  The  distinction  is  necessary  for  maintenance 
accountability. 

Post-Delivery  Software  Audits  are  another  important  technique 
for  handling  operational  software  maintenance.  During  the  life-cycle 
maintenance  of  computer  programs,  revisions  to  documentation  and  soft- 
ware will  be  required.  The  changes  result  from: 

1*  Navy  at-sea  tests, 

2.  Fleet-generated  Program  Change  Proposals  (PCP's)  or 
Trouble  Reports  (TRfs), 
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3.  Field  changes  to  improve  or  meet  changing  tactical  re- 
quirements, and 

4.  Engineering  Change  Proposals  (ECP's). 

It  is  therefore  necessary  to  periodically  re-audit  the  programs  and  docu- 
mentation to  assure  conformity  to  the  revised  technical  configuration 
identification  documents.  Post-delivery  audits  will  be  performed  by 
FCDSSA(DN)  in  conjunction  with  the  NAVSEA- as signed  program  maintenance 
activity  as  necessary  to  assure  complete  life-cycle  visibility  and  con- 
trol of  the  total  combat  system  software. 


4.8  HIGHLIGHTS 

DLGN-38  development  requirements  were  primarily  derived  from 
those  of  the  immediately  preceding  frigate  class  (which  was  itself  still 
in  development).  (MP1) 

The  DLGN-38  Command  and  Control  System  (C&CS)  has  signifi- 
cantly overrun  allocated  computer  resources.  This  can  be  attributed  to 
changing  and  growing  requirements  during  system  development  and  errors 
in  contractor  estimates  of  module  size.  (MP1,SE2) 

Rigorous  controls  over  program  development  are  ensured  by  a 
well-defined  and  concise  Management  Plan  (which  is  strictly  followed). 
This  plan  includes: 

1.  Specific  statement  of  objectives  and 

2.  Identification  of  tasks,  responsible  person  or  agency, 

dates,  and  deliverable  items.  (API) 

The  Integrated  Combat  System  Management  Plan  (ICSMP)  is  de- 
rived from  the  DLGN-38  Ship  Acquisition  Plan.  The  ICSMP  provides  for 
management  of  combat  system  integration  by  establishing  and  coordinat- 
ing the  schedules,  work  plans,  and  facility  requirements  of  agencies 
participating  in  development.  The  tasks  of  this  document  provide  guid- 
ance for  the  overall  Combat  System  Test  Plan  (CSTP) . (API) 

The  DLGN-38  Sensor  Interface  Data  System  (SIDS)  is  the  first 
Navy  attempt  at  an  automated  integrated  sensor  system.  The  SIDS/C&CS 
computer  complex  is  also  a pioneering  example  of  separate  software  sys- 
tem developments  within  a shared-memory  and  multiprocessing  architec- 
ture. (SE1) 

Standards  in  force  at  the  time  of  Contract  Definition  were  ap- 
plied to  the  selection  of  computer  type,  peripheral  and  switching  equip- 
ment, consoles,  language,  and  documentation.  This  facilitated  the  pro- 
curement, development,  and  integration  processes.  (SE1) 
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Software  control  is  vested  in  the  Software  Conf iguration  Con- 
trol Board  under  the  direction  of  the  Fleet  Combat  Direction  Systems 
Support  Activity  (FCDSSA(DN) ) . This  board  exercises  control  through  a 
series  of  reviews  and  audits.  Its  establishment  has  resulted  in  a sin- 
gle agency  (FCDSSA)  being  assigned  the  responsibility  for  implementation 
of  design  audits,  Interface  Design  Specifications  (IDS),  and  software 
Engineering  Change  Proposals  (ECP) . SHAPM  has  secured  permission  from 
OPNAV  for  FCDSSA  to  report  directly  to  SHAPM  for  this  function. 

(SE1 ,MS3) 

Early  design  freeze  followed  by  program  certification  prior  to 
delivery  provides  stable  program  development  control.  (SE3) 

Extensive  verification  activity  has  been  carried  out  at  the 
Mare  Island  Test  Site  to  determine  that  the  Interface  Design  Specifica- 
tions (IDS)  had  been  correctly  implemented.  A separate  facility  is  being 
assembled  at  FCDSSA(DN)  for  operational  support  and  operator  training. 
Simulation  programs  for  subprogram  development  were  funded  as  a recog- 
nized element  of  the  program.  (IP1,MS3) 

Continuing  individual  responsibility  follows  through  both  in- 
dustrial and  Navy  testing,  thus  assuring  continuity  of  program  valida- 
tion. (MSI ,MS2 ,MS3) 

Management  and  configuration  control  is  facilitated  by  estab- 
lishing baselines.  These  baselines  serve  as  technical  references  from 
which  the  system  elements  will  evolve  to  become  operational  systems. 

Since  MIL-STD-480  and  NAVMATINST  4130. 1A  do  not  detail  the  configura- 
tion control  of  computer  programs  to  the  degree  necessary  for  DLGN-38 
Class  combat  systems,  the  Software  Configuration  Control  Procedures 
Manual  expands  basic  terms  and  adds  new  terms  where  necessary.  (AM2) 
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5.  AIRCRAFT  CARRIER  (CV)  TACTICAL  DATA  SYSTEM 


5.1  GENERAL  SYSTEM  DESCRIPTION 

The  carrier  forces  planned  for  the  U.S.  Navy  will  consist  of 
12  ships  divided  into  two  Fleets,  the  Atlantic  and  the  Pacific.  Four  of 
the  12  carriers  are  or  will  be  nuclear  powered,  giving  them  the  advan- 
tage of  being  able  to  make  long  transits  and  remain  on  station  for  ex- 
tended periods  without  refueling  main-ship  propulsion. 

Aircraft  carriers  can  be  assigned  strike,  support,  or  antisub- 
marine warfare  (ASW)  missions , or  any  combination.  Their  primary  mis- 
sion is  to  support  embarked  operational  aircraft,  to  attack  targets  that 
threaten  control  of  the  task  force,  and  to  support  sustained  operations 
of  other  forces  as  assigned.  The  fighter- interceptor  complement  of  the 
carrier  air  wing  provides' Fleet  long-range  task  group  air  defense  capa- 
bility. Effective  adjuncts  of  the  carriers'  sensor  systems  are  embarked 
airborne  early  warning  (AEW)  aircraft  with  their  HF  data  link  capability. 
A vital  element  of  fighter  defense  is  the  additional  UHF  data  link  be- 
tween the  ship,  AEW  aircraft,  and  interceptor  aircraft. 

Every  carrier  has  two  operational  centers  that  deal  with  the 
command  and  control  of  aircraft:  the  Combat  Information  Center  (CIC) 

and  the  Carrier  Air  Traffic  Control  Center  (CATCC) . Each  has  its  own 
supporting  sensors.  The  CIC  is  concerned  with  the  management  of  weapons 
for  defense,  the  Naval  Tactical  Data  System  (NTDS)  is  an  essential  part 
of  its  operational  support.  The  CATCC  is  concerned  with  the  safety  of 
embarked  aircraft.  The  CIC  and  CATCC  aboard  the  modern  carrier  are  auto- 
mated for  high-capacity  aircraft  control. 

The  main  system  elements  include  sensors,  Combat  Direction/ 
Weapon  Direction  Systems  (CDS/WDS) , missile  systems,  Air-Traffic  Control 
(ATC)  systems,  electronic  support  measures  (ESM)  and  electronic  warfare 
(EW)  equipment,  and  voice  and  digital  communication  link  equipment.  The 
sensors  and  the  missile  systems  differ  among  the  CV's  since  independent 
configuration  update  programs  are  constantly  in  progress. 

5.1.1  Sensors 

Search  radars  and  associated  identification  friend  or  foe  (IFF) 
systems  provide  the  capability  for  detection  and  identification  of  air 
and  surface  targets  within  horizon  ranges.  The  typical  search  radars 
consist  of  the  medium-range  surface  search  radar  AN/SPS-10,  the  three- 
coordinate  long-range  air  search  radar  AN/SPS-48,  and  the  two  coordinate 
long-range  air  search  radar  AN/SPS-43.  Several  carriers  have  SPS-39  or 
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SPS-30  radars  instead  of  the  SPS-48,  and  the  SPS-12  and  SPS-37  radars 
instead  of  the  SPS-43.  IFF  capability  is  provided  by  the  Automatic 
Identification  Mk  XII  System  (AIMS)  (or  Mk  X).  Air-traffic  control  is 
provided  by  the  AN/SPN-43  radar,  a two-coordinate  ATC  unit. 

IFF  video  processing  equipment,  namely  the  Beacon  Video  Pro- 
cessor (BVP) , operates  upon  analog  IFF  data  to  provide  digital  automatic 
identification  and  positioning  of  friendly  aircraft  suitably  equipped. 
The  BVP  contains  a general-purpose  digital  computer,  CP-789/UYK.  A 
video  processor  designated  the  Signal  Data  Converter  operates  on  the 
AN/SPS-43  and  SPS-12  video  to  provide  digitized  video  and  azimuth  infor- 
mation, but  it  is  being  replaced  with  a variety  of  digitizers. 

5.1.2  Combat  Direction  System 

The  combat  direction  operations  are  handled  through  NTDS . 

NTDS  provides  data  entry  and  display,  automatic  data  processing,  com- 
munication link  control,  and  Weapon  System  designation  control.  NTDS 
equipment  includes  four  general-purpose  digital  computers  (CP-642 /USQ) , 
256k  of  extended  memory,  20  to  24  operator  data  entry  and  display  con- 
soles (AN/SYA-1,  SYA-4,  UYA-1,  or  UYA-4) , a variety  of  data  conversion 
and  designation  equipment,  and  various  peripheral  devices  including 
digital  data  link  units  and  analog  converters. 

5.1.3  Weapon  Direction  System 

The  WDS  Mk  5 Mod  2 is  interfaced  with  the  NTDS  and  provides 
coordination  and  control  of  the  missile  Weapons  Systems. 

Most  CV*s  have  either  the  Terrier  guided  missile  system  or  the 
Basic  Point  Defense  (BPD)  system.  CV-63  (and  possibly  others)  have  the 
NATO  Sea  Sparrow  Missile  System  (NSSMS) . 

The  Terrier  ships  use  three  guided  missile  fire  control  sys- 
tems (GMFCS)  Mk  76  Mod  3;  the  BPD  ships  use  either  two  or  three  GMFCSfs 
Mk  115  Mod  0. 

5.1.4  Carrier  Air-Traffic  Control  System 

The  ATC  function  is  integrated  with  the  NTDS  and  is  designated 
collectively  as  Carrier  Air-Traffic  Control  (CATC).  The  functions  of 
marshalling  and  departure  are  handled  through  four  operator  consoles  of 
the  NTDS.  Sensors  and  tracking  systems  associated  with  CATC  approach 
are  the  two-coordinate  ATC  radar  AN/SPN-43  and  the  landing  control  sys- 
tem AN/SPN-42.  The  AN/SPN-42  includes  two  guidance  (tracking)  radars 
and  two  general-purpose  digital  computers  (Univac  1219). 
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5.1.5  Electronic  Support  Measures  and  Electronic  Warfare  Equipment 

ESM  equipment  consists  of  an  electronic  countermeasures  (ECM) 
receiving  set,  the  AN/WLR-1  and,  on  several  CV's,  the  AN/SLR-13.  EW 

equipment  consists  of  countermeasures  set  AN/ULQ-6 , which  is  interfaced 
with  the  NTDS. 

5.1.6  Communication  Links 

The  communication  links  interfaced  with  the  NTDS  are  Link  11 
(computer-to-computer  with  other  NTDS  ships),  Link  4A  (digital  control 
information  to  aircraft) , and  Link  14  (NTDS  station  to  non-NTDS  station) . 

5.1.7  Acquisition  History 

The  Fleet  Combat  Direction  System  Support  Activity  (FCDSSA)  at 

San  Diego  (SD)  has  the  responsibility  for  developing  and  maintaining 
NTDS  software  for  this  class  of  ship.  FCDSSA(SD)  designed  and  imple- 
mented the  NTDS  program  for  the  CV,  CG,  DLG-28  Class,  and  LCC.  The  de- 
velopment of  the  NTDS  program  for  the  CV  used  previously  developed 
FCDSSA  NTDS  programs  as  a baseline  design. 

Each  CV  Operational  Program  is  designated  by  a model  and  phase 
number.  A model  change  involves  a change  in  intership  Link  11  message 
formats.  A program  may  also  be  restructured  when  a model  change  is  re- 
quired. A phase  change  typically  occurs  every  2 years.  It  incorporates 
into  the  program  library  all  minor  changes  that  have  accumulated  in  that 
time  and  that  have  been  patched  or  deferred. 

The  NTDS  program  for  the  CV  was  developed  at  FCDSSA  using  in- 
house  personnel  to  generate  the  Functional  Operational  Design  and  level- 
o effort  contracting  to  generate  the  program  design  and  code  for  each 
user  module.  The  contractor  worked  at  the  FCDSSA  facility  which  pro- 
vided the  necessary  equipment  and  support  software.  All  software  design 
at  FCDSSA(SD)  is  done  by  in-house  personnel,  and  Navy  software  is  used 
as  the  basis  for  all  program  development. 

Prior  to  1973  there  were  attack  carriers  (CVA's)  and  ASW  car- 
riers . (CVS  s).  The  difference  in  the  tempo  of  operations  made  it  im- 
practical to  mix  the  attack  and  ASW  missions.  Moreover,  the  ASW  mission 
was  not  supported  by  the  NTDS.  With  the  introduction  of  the  S-3  Viking 
aircraft,  it  was  decided  that  any  carrier  should  conduct  any  mission. 

Therefore,  in  1975,  carriers  are  deploying  with  both  attack  and  ASW  air- 
craft  aboard. 


In  1974,  the  first  F-14  squadron  deployed  on  carriers.  The 
data  link  associated  with  this  aircraft  required  a small  change  in  NTDS 
LdF  link  software  to  use  feed-back  data  from  the  aircraft. 
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5.1.8  System  Diagram 

A system  block  diagram  for  a representative  carrier  tactical 
data  system  is  shown  in  Fig.  5-1.  Functional  relationships  among  the 
primary  system  elements  are  indicated  on  the  figure. 
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5.2  COMPUTER  SYSTEM  ARCHITECTURE 

5.2.1  Computer  Characteristics 

Carrier  tactical  data  systems  with  either  the  Terrier  missile 
or  the  BPD  system  include  either  eight  or  nine  general-purpose  digital 
computers.  The  ninth  computer  is  the  Control  Format  Unit  (CFU)  which 
is  not  installed  on  all  CV's.  Carriers  with  the  NSSMS  include  the  CFU 
and  a tenth  digital  computer,  fire  control  Mk  157.  Table  5-1  presents 
a summary  of  these  computers.  The  unit  designation  (S,  N,  Cl,  etc.)  is 
keyed  to  the  system  diagram,  Fig.  5-1. 


Table  5-1 

CV  COMPUTER  SUMMARY 


Unit 

Type 

Function 

Pro- 

cessor 

Memory 

S 

CP-789/UYK 

Beacon  video  processing:  friendly 

i 

16k 

(18  bit,  4 ys) 

identification,  detection  and  track 

N 

CP-642B/USQ-20 

Navigation 

i 

32k 

\ 

(30  bit,  A ys) 

Cl 

CP-6A2B/USQ-20 

i 

32k 

(30  bit,  A ys) 

C2 

CP-6A2B/USQ-20 

NTDS:  Rate- aided  tracking,  air 

i 

32k 

(30  bit,  A ys) 

traffic  control,  identification, 

C3  i 

CP-6A2B/USQ-20 

threat  evaluation  and  weapon 

(30  bit,  A ys) 

assignment,  display,  communications 

i 

32  k 

C4  | 

CP-6A2B/USQ-20 

(30  bit,  A ys) 

i 

32k 

Ml 

MU-602 (V) /UYK 

Extended  Core  Memory  Unit  (ECMU)(642) 

256k 

CF 

CP-7  89/UYK 

CFU:  interface  control  and  data 

i 

16k 

(18  bit,  A ys) 

conversion 

A1,A2 

CP-8A8/UYK 

Precision  tracking  for  aircraft 

2 

16k 

(18  bit,  2 ys) 

landing  control 

(total) 

W1 

Mk  157 

Missile  fire  control 

1 

16k 

(16  bit,  1 ys) 
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Future  modifications  to  on-board  carrier  systems  will  include 
improvements  in  data  link  systems  and  command  control  communications 
systems  equipment. 

There  are  five  CP-642B/USQ-20  computers  (CVAN-68;  alternate 
configuration  is  four  CP-642A/USQ-20  and  one  CP-642B/USQ-20) . This 
computer  has  a 30  bit  word  length,  a 32k  word  memory,  a 4 ys  cycle  time 
(8  ys  for  CP-642A) , and  an  instruction  set  of  62  instructions.  There 
are  eight  32k  30  bit  word  executable  instruction  memory  units  available 
to  four  of  the  642Ts. 

There  are  one  or  two  CP-789/UYK  computers  (Univac  1218);  the 
second  is  designated  the  CFU.  This  computer  has  an  18  bit  word  length, 
a 16k  word  memory,  a 4 ys  cycle  time,  and  an  instruction  set  of  98  in- 
structions. 

There  are  two  CP-848/UYK  (Univac  1219)  computers,  which  are 
similar  to  the  Univac  1218 Ts.  The  1219  has  an  18  bit  word  length,  an 
8k  word  memory,  and  a 2 ys  cycle  time. 

Computer  peripherals  which  support  the  operation  of  the  four 
NTDS  CP-642B  computers  include: 

1.  1 paper  tape  unit,  Signal  Data  Recorder  (reproducer) 
RD-231/USQ-20 , 

2.  2 magnetic  tape  units,  RD-243/USQ-20 , 

3.  2 system  monitoring  panels,  C-3674A/USQ-20,  and 

4.  5 universal  keysets  MX-3195 (V) /USQ-20. 

5.2.2  Interrelation  among  Computers 

The  NTDS  unit  computer  with  the  ECMU  is  the  primary  CDS  data 
processing  element.  The  Ship’s  Inertial  Navigation  System  (SINS)  com- 
puter and  the  BVP  computer  provide  data  to  the  NTDS  unit  computer  over 
peripheral  input/output  (I/O)  channels.  The  CFU  interfaces  with  the 
NTDS  unit  computer  over  a peripheral  I/O  channel.  The  Univac  1219  com- 
puters of  the  aircraft  landing  system  interface  with  the  NTDS  unit  com- 
puter over  one  peripheral  I/O  channel. 

Corresponding  I/O  channels  of  the  four  NTDS  CP-642B  computers 
are  generally  dedicated  to  the  same  interface  function.  A switching 
arrangement  connects  each  particular  interface  to  an  I/O  channel  of  one 
of  the  four  NTDS  computers.  The  four  NTDS  computers  are  interconnected 
by  both  intercomputer  channels  and  peripheral  channels.  Two  peripheral 
equipment  simulators,  CV-302/UYK,  are  required  for  the  peripheral  I/O 
channel  interface. 
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In  the  past,  the  configuration  of  the  four  NTDS  computers 
without  ECMU  had  resulted  in  a large  amount  of  intercomputer  data 
transfer.  This  occurred  because  a substantial  number  of  program  modules 
located  in  more  than  one  of  the  computers  obtained  data  from  or  provided 
data  to  a peripheral  connected  to  an  I/O  channel  of  one  computer.  The 
intercomputer  data  transfer  is  overhead,  as  it  does  not  involve  either 
mathematical  or  logical  operations.  The  ECMU  permits  communication  of 
each  computer  with  the  memory  unit  without  intercomputer  connection, 
solving  the  problem. 

5.2.3  Functional  Allocation  among  Computers 

Four  of  the  CP-642B  computers  are  the  data  processing  element 
of  the  NTDS.  These  computers  are  linked  together  by  intercomputer  and 
peripheral  I/O  channels  and  are  designated  as  the  NTDS  unit  computer, 
in  association  with  the  eight-unit  extended  memory.  The  NTDS  unit  com- 
puter provides  rapid  assembling  and  maintaining  of  target  data  and  ATC 
data,  performs  mathematical  and  logical  operations,  presents  situation 
summary  displays  to  operators,  provides  recommended  courses  of  combat 
direction  action,  designates  target  data  to  the  missile  system  and  to 
aircraft,  and  finally  designates  position  data  to  the  ATC  landing  sys- 
tem for  final  approach. 

The  fifth  CP-642B  computer  supports  the  SINS  as  a peripheral 

system. 


The  first  of  the  CP-789  computers  is  part  of  the  BVP  system. 

The  second  CP-789  computer  is  the  CFU,  which  provides  a data  interface 
between  the  NTDS  unit  computers  and  the  display  system,  the  Keyset  Cen- 
tral Multiplexer  (KCMX) , and  several  other  computer  peripherals. 

The  two  Univac  1219  computers  are  part  of  the  aircraft  landing 
system,  AN/SPN-42.  Each  computer  performs  a director  feed-back  function 
similar  to  that  of  a fire  control  system  and  supports  a tracking  channel 
of  the  AN/SPN-42  for  close  control  during  the  landing  evolution. 

5.2.4  Functional  Interfaces  with  Sensors 

NTDS  has  the  primary  responsibility  for  the  tactical  processing 
of  data  derived  from  the  CV  sensor  system  preprocessor.  All  sensor  data 
(with  the  exception  of  certain  classified  IFF  data)  are  input  to  the  NTDS 
operational  program  via  operator  action  or  by  operator  monitor  at  either 
general-purpose  display  consoles  or  special-purpose  keyset  equipment. 
Search  radar  video  data  are  entered  via  the  display  system  complex;  elec- 
tronic countermeasures  data  and  fire  control  radar  data  are  entered  via 
the  signal  conversion  equipment  of  the  KCMX.  Automatic  (computer-to- 
computer)  input  of  selected  IFF  data  and  automated  search  radar  data  in- 
put are  accomplished  through  the  BVP  equipment  and  the  pertinent  prepro- 
cessing search  radar  computers  (video  processors) , respectively. 
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5.2.5  Functional  Interfaces  with  Weapons 

NTDS/WDS  provides  the  primary  data  interface  with  CV  Weapon 
Systems.  Target  designation  by  NTDS  computer  to  the  missile  systems  is 
accomplished  via  the  signal  conversion  equipment  of  the  KCMX,  which  in- 
terfaces with  the  CFU  or  directly  with  the  NTDS  unit  computer. 

5.2.6  Functional  Interface  with  Air -Traffic  Control 

CATC  is  integrated  with  the  NTDS.  The  CATC  function  consists 
of  all  ATC  operations  except  final  approach,  which  is  controlled  by  the 
AN/SPN-42  system.  There  are  three  subfunctions  associated  with  CATC: 
departure,  marshalling,  and  approach.  Two  NTDS  operator  consoles  are 
used  for  approach  control  and  one  console  each  for  marshalling  and  de- 
parture. One  aircraft  entry  keyset  is  used  with  CATC  to  enter  various 
aircraft  data  into  the  NTDS. 

Approach  control  consists  of  aircraft  control  from  the  mar- 
shalling point  through  the  landing  pattern  to  start  of  final  approach. 
Final  approach  begins  at  about  3 to  5 nm.  At  the  start  of  final  ap- 
proach, the  aircraft  are  designated  by  the  NTDS  unit  computer  to  the 
AN/SPN-42  computer  system. 

Marshalling  control  consists  of  controlling  aircraft  upon 
arrival  at  the  marshalling  area,  about  40  to  50  nm,  and  proper  turnover 
of  the  aircraft  to  approach  controllers. 

Departure  control  consists  of  tracking  aircraft  launched  from 
the  ship  until  the  aircraft  are  assigned  to  a tactical  air  controller. 

5.2.7  Casualty  Operation 

NTDS  computer  casualty  operation  consists  of  operation  with 
one,  two,  or  three  of  the  NTDS  computers  at  correspondingly  reduced 
levels,  without  the  ECMU. 


5.3  COMPUTER  PROGRAM  ARCHITECTURE 

5.3.1  Naval  Tactical  Data  System  Computer  Program 

The  NTDS  operational  program  and  its  associated  equipment  suite 
comprise  the  operational  equipment  center  of  CV  CDSTs.  As  such,  the 
NTDS  supports  command  and  control  for  the  ship  by  supplying  the  ship 1 s 
command  and  control  operating  personnel  with  systematically  processed, 
and  real-time  evaluated,  tactical  situations  of  ownship  and  other  mem- 
bers of  the  force  and  by  specifying  the  actions  recommended  in  response 
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to  the  input  tactical  environment.  A recent  significant  additional  fea- 
ture of  the  NTDS  operational  program  is  the  inclusion  of  a defense  con- 
trol capability  against  antiship  missile  threats.  This  control  consists 
of  the  implementation  of  automatic  threat  recognition  action  and  assign- 
ment of  Sensor/Weapon  Systems  against  targets  that  are  considered  immi- 
nent threats. 

5.3.2  Naval  Tactical  Data  System  Program  Architectural  Structure 

The  NTDS  operational  program  is  a modular,  multicomputer  pro- 
gram that  is  coded  and  compiled  utilizing  the  CS-1  and  CMS-2  languages. 
Each  module  is  named  after  a functional  unit,  i.e.,  it  is  allocated  pro- 
cessing responsibility  for  a function  or  group  of  related  functions. 

Module  functional  responsibility  is  often  allocated  according  to  equip- 
ment and  software  interface  performance.  However,  the  total  processing 
of  the  data  transferred  across  the  interface  is  not  necessarily  assigned 
to  the  interfacing  module  but  may  be  distributed  via  the  executive  be- 
tween several  modules  dependent  upon  the  utilization  of  the  data.  The 
Display  (DS)  module,  which  is  responsible  for  servicing  (performing  the 
interface  with)  the  consoles,  is  an  example  of  this  type  of  module,  i.e., 
interfacing  with  many  others  through  the  software  executive. 

Several  of  the  NTDS  program  modules  are  responsible  for  imple- 
menting functions  required  by  all  other  modules  in  the  program  and  by 
other  elements  of  the  NTDS.  These  modules  provide  executive  control  over 
all  real-time  and  periodic  processing  references  that  are  granted  to  each 
module;  they  provide  the  capability  of  transferring  data  among  modules  of 
the  NTDS  operational  program  and  between  the  four  CP— 642B  computers  and 
the  ECMU  in  which  the  modules  reside;  and  they  provide  the  means  whereby 
control  over  system  operation  and  system  reconfiguration  may  be  exercised 
by  operational  system  personnel.  The  remaining  modules  that  comprise  the 
NTDS  operational  program  are  responsible  for  processing  the  information 
gathered  from  sensors,  weapons,  intelligence,  ownship  support  system,  and 
other  units  of  the  force,  and  for  providing  the  information  to  the  NTDS 
console  operators  in  a meaningful  format.  By  evaluating  the  data  pro- 
vided by  the  program  modules  via  the  console  displays,  NTDS  personnel  are 
capable  of  rapidly  responding  to  any  tactical  situation. 

Dynamic  modular  replacement  (DMR)  is  a technique  that  allows  an 
NTDS  operational  program  to  be  reconfigured  by  the  addition  or  deletion  of 
certain  modules  from  computer  core  when  no  ECMU  is  available.  This  can 
be  accomplished  during  program  execution  without  disruption  to  normal 
tactical  operations.  DMR  helps  overcome  recent  core  limitation  con— 
straints  on  the  size  of  the  operational  program,  while  providing  the  capa- 
bility for  satisfying  several  diverse  mission  requirements  with  a single 
computer  suite.  Modules  that  are  entered  into  fixed  core  locations  at 
program  loading  are  referred  to  as  resident  modules.  Modules  that  can  be 
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dynamically  added  or  deleted  from  the  program  during  execution  are  re- 
ferred to  as  transient  modules.  Transient  modules  are  compiled  in 
relative  format  at  a standard  base  address.  As  in  other  NTDS  ships, 
transient  modules  are  entered  into  core  from  a magnetic  tape  unit.  Ap- 
proximately 20k  words  of  one  computer  are  currently  reserved  for  tran- 
sient modules,  when  no  ECMU  is  installed. 

The  basic  structure  of  all  NTDS  modules,  resident  and  tran- 
sient, includes  a data  section  and  an  instruction  section.  The  data 
section  includes  local  data  for  module  use  only,  executive  interface 
data  to  be  used  in  the  transfer  of  Central  Processing  Unit  (CPU)  con- 
trol to  the  executive,  and  a storage  area  for  messages  received  from 
other  modules  via  the  executive.  The  instruction  section  includes  a 
real-time  (console)  instruction  set  and,  if  appropriate,  will  also  in- 
clude a periodic  (monitor)  instruction  set  and/or  an  equipment  (inter- 
rupt) interface  instruction  set.  The  executive  system  controls  entry 
into  a module1 s real-time,  periodic,  or  equipment  processor  programs. 
Each  module  has  a unique  priority  designator  which  indicates  when  CPU 
control  will  be  transferred  to  its  specific  processing  tasks.  This 
designator  is  a part  of  the  executive  interface  data  contained  in  the 
module1 s data  section. 

5*3.3  Naval  Tactical  Data  System  Program  Executive  System 

The  NTDS  executive  system  is  constructed  in  four  functional 
sections.  These  sections  are  designated  as  Common  Control  (CC) , Execu- 
tive (EX),  Intermodule/Intercomputer  (IMIC),  and  Data  Update  (DU).  An 
identical  executive  system  resides  in  each  of  the  CP-642A  computers 
used  by  the  operational  program  without  ECMU,  and  CPU  and  I/O  processing 
in  all  computers  proceeds  independently  and  simultaneously.  Control  is 
transferred  to  the  executive  system  of  each  computer  after  the  program 
has  been  loaded  and  brought  on  line. 

The  executive  system  Common  Control  section  contains  a com- 
mon data  area  and  an  area  for  common  processing  routines.  These  items 
can  be  referenced  by  any  module,  as  required.  The  common  data  area  con- 
tains mathematical  routines  such  as  sine,  cosine,  and  square  root.  It 
also  contains  other  routines  such  as  those  required  for  message  data 
packing  and  preset  operations.  When  ECMU  is  available,  most  of  these 
tables  are  in  the  (shared)  ECMU  memory. 

The  Executive  section  is  responsible  for  maintaining  program 
control  over  all  modules  resident  within  its  computer.  It  schedules  all 
real-time  and  periodic  references  to  each  of  the  modules  using  that  com- 
puter’s I/O.  Task  scheduling  is  accomplished  according  to  a predefined 
priority  scheme  that  is  based  both  on  the  module’s  servicing  priority 
and  on  whether  the  required  module  task  is  a real-time  (console)  task 
or  a periodic  (equipment)  task.  The  Executive  section  is  made  up  of 
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three  segments.  These  are  a display  initiation  subexecutive,  a real- 
time subexecutive,  and  a periodic  subexecutive.  The  highest  priority 
is  given  to  display  initiation  tasks.  Tasks  are  serviced  in  priority 
order  for  each  Executive  section  cycle  so  that  real-time  tasks  are  not 
serviced  if  there  are  any  display  initiation  tasks  to  be  completed,  and 
periodic  tasks  are  not  serviced  if  there  are  any  real-time  tasks  to  be 
completed.  Display  initiation  tasks  are  executed  only  in  the  computer 
interfacing  with  the  display  system  complex  etc. 

The  executive  system's  Data  Update  section  is  responsible  for 
entering,  updating,  and  clearing  data  in  the  data  stores  area  of  the 
Common  Control  section  or  of  the  ECMU.  Messages  are  transferred  to  the 
Data  Update  section  via  the  IMIC  section.  Messages  from  any  module  that 
are  addressed  to  the  Data  Update  section  are  sent  to  the  Data  Update 
sections  of  all  of  the  system's  computers  that  do  not  have  an  ECMU.  The 
structure  of  the  Data  Update  section  of  the  executive  system  is  similar 
to  that  of  the  basic  program  module,  and,  in  program  execution,  Data 
Update  is  given  the  highest  priority  for  real-time  processing.  This 
ensures  that  program  common  stores  are  always  updated  at  the  first  avail- 
able opportunity. 

5.3.4  Naval  Tactical  Data  System  User  Module  Functions 

The  modules  of  the  CV  NTDS  operational  program  that  serve 
equipment  and  console  operators  directly  and  a brief  description  of 
their  primary  functions  are  given  in  Table  5-2.  There  is  no  direct 
relationship  between  the  program  structure  and  either  the  NTDS  func- 
tions (defined  by  the  Functional  Operational  Design)  or  operator  sta- 
tions (consoles).  Generally,  more  than  one  operator  function  will  be 
accommodated  at  a program  module.  Program  modules  can  perform  opera- 
tions related  to  more  than  one  function,  and  several  program  modules 
can  perform  operations  affecting  a particular  operator  station. 

5.3.5  Time  and  Core  Requirements 

The  current  CV  NTDS  operational  program  uses  essentially  all 
of  the  available  time  and  core  in  the  four  CP-642B  computers.  The  DMR 
capability  was  developed  because  there  was  not  sufficient  core  for  all 
the  modules  to  be  in  the  computers  at  once  without  ECMU. 

Memory  expansion  equipment  being  installed  will  increase  the 
ship's  NTDS  computer  core  capacity  by  256k  (the  equivalent  of  eight  com- 
puters). Additional  memory,  rather  than  additional  computers,  will  be 
used  to  alleviate  both  a major  core  problem  and  a timing  problem.  The 
timing  problem  is  caused  primarily  by  the  large  amount  of  intercomputer 
data  transfer  required  to  transfer  data  among  the  modules  and  periph- 
erals connected  to  each  of  the  four  USQ-20  computers  without  ECMU.  The 
expanded  memory  will  permit  access  to  every  location  in  ECMU  by  each 


5-11 


5-12 


TABLE  5-2 

CV  NTDS  PROGRAM  MODULES 

Module 

Primary  Function 

Air  Traffic  Control 

Provides  ATC  functions  for  the  carrier.  Supports  the  Depar- 
ture Controller,  Marshall  Controller,  and  Letdown  Controller 
console  modes.  Two  versions  of  this  module  are  available  with 
different  aircraft  handling  capacities. 

Basic  Training 

Simulation  of  a realistic  tactical  environment  for  training  pur- 
poses. Includes  simulation  of  radar  returns  for  display  on  con- 
soles. Supports  the  Training  Supervisor  mode. 

Beacon  Video  Processor 

Provides  interface  between  NTDS  program  and  BVP  equipment.  Pre- 
processes  target  position  data  as  automatically  generated  by 
BVP.  Supports  Selective  Identification  Feature  (SIF)  Tracker 
console  mode. 

Combat  Systems  Operability  Test 

Processes  and  prints  out  selected  data  extraction  events. 

Common 

Provides  storage  areas  required  to  contain  those  data  stores 
and  subroutines  that  are  most  frequently  utilized  by  other 
modules . 

Control  Formatter  Interface 

Performs  interface  functions  between  the  NTDS  and  CFU  programs. 

IMIC  Communications 

Transfers  all  intermodule  and  intercomputer  messages. 

Data  Extraction 

Controls  the  extraction  and  recording  on  magnetic  tape  of  sys- 
tem operational  data. 

Data  Update 

Maintains  the  common  data  stores  in  each  of  the  NTDS  computers. 

Display 

Provides  interface  between  console  operators  and  the  NTDS  pro- 
gram via  the  display  subsystem.  Supports  all  console  displays 
and  pushbutton  operations. 
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Module 

Primary  Function 

Dynamic  Modular  Replacement 

Master  provides  for  modification  of  program  configuration.  Slave 
supports  bookkeeping  functions  in  non-master  computers. 

Electronic  Warfare 

Provides  interface  between  NTDS  program  and  ECM  equipment.  Sup- 
ports EW  supervisors. 

Executive 

Maintains  program  control  and  schedules  all  modules  resident  in 
computer. 

Height/Size 

Processes  air-track  height  and  size  data  inputs  from  Height/Size 
console  mode. 

Identification 

Establishes  the  identity,  class,  and  category  of  all  local 
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tracks  based  on  manual  and  automatic  inputs.  Supports  the 
Identification  console  mode. 

Intercept  Control 

Supports  intercept  controller  tasks  for  vectoring  interceptors 
to  attack  positions.  Calculates  pursuit  or  collision  geome- 
tries . 

Link  4A 

Provides  an  interface  between  the  NTDS  program  and  the  Link  4A 
Communications  equipments. 

Link  14 

Selects  and  formats  NTDS  tactical  data  items  and  supplies  them 
for  broadcast  to  non-NTDS  ships  in  the  force. 

Link  11 

Transmits  data  assembled  by  other  modules  on  Link  11  terminal 
and  routes  data  received  from  terminal  to  appropriate  module  for 
decoding  and  use. 

Point  Defense 

Provides  interface  with  Basic  Point  Defense  Surface  Missile  Sys- 
tems (BPDSMS).  Provides  target  designations  to  BPDSMS  and  re- 
ceiver repeat-back  data  from  BPDSMS. 
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Module 

Primary  Function 

Resident  Control 

Provides  interface  with  System  Monitoring  Panel  which  is  used 
for  loading  and  maintaining  the  program,  controlling  system 
operation,  and  controlling  DMR. 

SPN-10/42 

Interfaces  with  Automatic  Carrier  Landing  System.  Provides  tar- 
get designations  of  aircraft  in  letdown  phase  for  final  approach 
and  landing  control. 

Surface  Maneuvering 

Supports  the  Command  Bridge  console  mode  which  monitors  all  air, 
surface,  and  subsurface  tactical  situations  as  they  affect  ship f s 
operation. 

Surface  Operations 

Maintains  position  and  velocity  of  ownship,  special  moving  points, 
and  fixed  geographic  points. 

Ul 

i 

i 

£ System  Tracker 

Encodes  and  decodes  data  transferred  to  and  received  from  Link  11. 
Determines  reporting  responsibility  for  Link  11  tracks,  decor- 
relation of  local  and  remote  tracks,  and  computation  of  gridlock 
and  intership  radar  alignment  corrections. 

Threat  Weapons  Assignment 

Performs  threat  evaluation  on  targets  with  respect  to  ownship. 
Performs  weapons  assignment  and  engagement  functions  for  missiles, 
guns,  interceptors,  UV,  chaff,  active  ECM,  and  passive  ECM  sys- 
tems. Supports  Force  Weapons  Coordinator,  Flag  Command,  Shipfs 
Weapon  Coordinator,  and  Ship  Anti-Missile  Coordination  console 
modes . 

Tracking 

Performs  tasks  associated  with  rate-aided  tracking  based  on  track 
position  data  entries.  Supports  Detector  Tracker,  Track  Super- 
visor, Air  Tracker,  Surface  Tracker,  and  SIF  Tracker  console  modes. 

Utility  Processor 

Processes  selected  General  Purpose  Function  Code  (GPFC)  entries 
from  operators  requesting  PPI  symbology  and  data  read-out  ampli- 
fication data  or  entering  certain  data. 
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computer.  With  the  expanded  memory,  there  will  be  no  need  for  inter- 
computer data  transfer  after  program  load,  and  consequently  the  total 
required  execution  time  will  be  greatly  reduced.  Also,  a load-leveling 
technique  used  in  the  executive  will  permit  balancing  the  processing 
load  equally  among  all  four  computers,  further  reducing  the  timing  prob- 
lem by  sharing  CPU’s  among  all  non-I/O  modules  in  ECMU. 


5.4  SOFTWARE  DEFINITION,  DESIGN,  AND  IMPLEMENTATION 

5.4.1  CV  Naval  Tactical  Data  System  Software  Definition  and  Design 

FCDSSA(SD)  designed,  developed,  and  implemented  the  NTDS  pro- 
gram for  the  CV  Class  ships.  The  development  of  this  program  used 
other  FCDSSA(SD)  NTDS  programs  as  a baseline  design,  thus  avoiding 
costly  redevelopment  and  helping  to  keep  NTDS  programs  uniform. 

The  documentation  used  for  the  definition  and  design  of  the 
CV  NTDS  program  is  summarized  in  Table  5-3.  The  purpose  and  content  of 
each  of  these  documents  (as  well  as  those  shown  in  Table  5-4)  are  de- 
scribed in  FCDSSA  Instruction  5600. 1C,  As  can  be  seen  in  Table  5-3, 
the  documents  fall  into  three  major  groups:  Navy  Requirements,  System 

Specifications,  and  Program  Specifications. 

5.4.2  CV  Naval  Tactical  Data  System  Software  Implementation 

The  development  or  preliminary  implementation  phase  consists 
of  achieving  a functional  capability  in  a computer  program  and  testing 
this  capability  to  ensure  that  it  satisfies  the  requirements  of  the  sys- 
tem. During  this  phase,  very  few  programming,  hardware,  or  documenta- 
tion change  restrictions  are  imposed  in  order  to  keep  the  software  flex- 
ible and  minimize  the  costs  of  changes. 

During  the  development  of  the  CV  NTDS  program  at  FCDSSA,  the 
documentation  consists  largely  of  functional  descriptions  with  minimal 
changes  to  implementation  methods.  Interfaces  between  software  and  hard- 
ware and  among  modules  are  documented  carefully,  while  the  internal 
workings  of  the  modules  are  usually  documented  in  extensive  listings 
from  the  high-level  compiler  used  (CMS-2).  The  documentation  used  dur- 
ing implementation  of  the  CV  NTDS  program  is  summarized  in  Table  5-4. 

After  a working  program  is  obtained,  the  implementation  is 
maintained  with  the  Program  Design  Specification  (PDS)  and  the  program 
Technical  Description  Document  (PTD) , which  is  primarily  the  listings  as 
annotated  by  programmers. 

Certain  programming  standards  were  used  in  the  CV  NTDS  pro- 
gram. These  were  largely  related  to  the  use  of  the  NTDS  executive  and 
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TABLE  5-3 

CV  NTDS  DEFINITION  AND  DESIGN  DOCUMENTATION 


Document  Type 

Document  Name 

Content 

Navy  Requirements 

Tactical  Operational  Re- 
quirement (TOR) 

Describes  in  operational  user  language  all  Tac- 
tical Data  System  (TDS)  functional  requirements 
that  have  been  established  for  a given  ship,  air 
craft,  or  shore-based  command  mission. 

System  Specifications 

System  Operational  Spe- 
cification (SOS) 

Describes  specific  operational  functions  in- 
cluding details  of  system  requirements  for 
the  required  mission,  doctrine,  operating 
environment,  and  operational  position.  Sys- 
tem constraints  including  hardware  descrip- 
tions are  also  described. 

System  Operational  Design 
(SOD) 

Describes  a plan  for  the  integrated  system 
program.  Contains  all  proposed  program  func- 
tion core  allocations,  all  subprogram  defini- 
tions and  their  interfaces,  and  overall  pro- 
gram data  development. 

Program  Specifications 

Functional  Operational 
Specification  (FOS) 

Specifies  each  required  action  at  each  opera- 
tor's position  and  the  use  of  each  periph- 
eral's I/O  capability.  Data  type  and  the 
processing  and  disposition  with  intercom- 
munication and  equipment  interfaces  are 
specified  for  each  operator  function  and 
for  each  unit  of  peripheral  equipment. 

Functional  Operational 
Design  (FOD) 

Describes  a functional  design,  in  operator 
function  terms,  for  each  console  (and  mode) 
operator  and  peripheral  equipment.  The  opera- 
tor or  equipment  actions,  data  sources,  con- 
trol requirements,  and  control  design  and  their 
interfaces  are  detailed. 
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TABLE  5-3  (cont'd) 


Document  Type 

Document  Name 

Content 

Program  Specifications 
(contT  d) 

Program  Performance  Spe- 
cification (PPS) 

Describes  computer  program  (Executive  system 
only)  in  terms  of  logical,  functional,  and 
mathematical  language. 

Interface  Design  Specifi- 
cations (IDS) 

Used  when  two  or  more  data  systems  are  inter- 
faced at  the  on-line  interdigital  processor 
level.  Describes  interchange  message  formats, 
content,  timing  requirements,  originating 
signal  source,  and  disposition  of  exchanged 
data. 
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TABLE  5-4 

CV  NTDS  IMPLEMENTATION  DOCUMENTATION  (Program  Description) 


Document  Name 

Content 

Program  Design  Specifica- 
tions (PDS) 

Contains  the  design  details  for  the 
digital  processor  program  in  program- 
ming language. 

Program  Technical  Descrip- 
tion Document  (PDD  or  PTD) 

Contains  the  design  details  for  each 
subprogram  of  the  digital  processor 
program  in  terms  of  programming  logic 
and  language.  It  presents  the  results 
of  the  programming  effort,  usually  in 
extensive  compiler  output  listings  with 
comments . 

Data  Base  Design  (DBD) 

Provides  a detailed  description  of  all 
data  items  that  are  required  by  more 
than  one  subprogram. 

Program  Package  (PP) 

Contains  all  items  necessary  for  the 
processing  agency  to  produce  and  main- 
tain the  computer  program,  including 
the  source  deck  and  listing,  object 
program  tape,  an  error-free  assembler/ 
compiler  listing,  and  a cross-refer- 
ence listing. 
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intermodule  communications  techniques,  so  that  the  executive  system 
could  be  supplied  as  a standard  package. 

Thus,  the  production  or  final  implementation  phase  takes  the 
proven,  functional  design  generated  in  the  development  phase  and  trans- 
forms it  into  a well-documented,  standardized,  maintainable  program. 

This  avoids  recompiling  for  a different  computer  or  in  a different  lan- 
guate  or  operating  from  a different  executive,  since  the  FCDSSA-devel- 
oped  CMS-2Q  contains  code  generators  for  several  Navy  computers. 

5.4.3  Program  Generation  and  Library  Facilities 

FCDSSA  has  developed  a four— bay  UYK-7  time— sharing  system 
called  SHARE- 7 which  it  uses  for  developing  NTDS  programs.  SHARE- 7 con- 
tains several  compilers  and  debug  aids.  An  NTDS  library  is  maintained 
on  disks  that  contain  all  the  CV  program  modules  in  addition  to  the 
modules  for  several  other  ship  classes.  The  content  of  this  library  is 
tightly  controlled.  The  listings  of  the  library  are  produced  on  micro- 
fiche and  on  tape  at  FCDSSA(SD) . 

The  operational  NTDS  program  for  the  CV  is  written  in  the 
CMS- 2 programming  language  developed  and  maintained  by  FCDSSA(SD) . The 
CMS-2  compiler  is  run  on  the  SHARE-7  system  (also  maintained  by  FCDSSA 
(SD)).  In  the  future,  the  FCDSSA(SD)  program  libraries  may  be  recom- 
piled to  the  UCMS-2  version  of  this  language.  Thi<?  is  a machine- inde- 
pendent language  and  FCDSSA  has  shown  that  its  use  will  ease  the  NTDS 
program  development  efforts  by  permitting  all  applications  modules  to 
be  used  on  different  machines  without  recompiling  or  reprogramming. 

5.4.4  Externally  Driven  Program  Modification 

The  addition  of  the  F-14  UHF  data  link  reply  operations  capa- 
bility to  the  CV  NTDS  program  provides  an  illustration  of  the  normal 
workings  of  the  definition,  design,  and  implementation  stages  of  FCDSSA. 
This  modification  involved  changing  the  intercept  control  and  Link  4 
modules  to  provide  for  the  new  F-14  downlink  capability. 

The  first  step  was  to  modify  the  System  Operational  Design 
(SOD)  describing  how  the  new  requirements  affected  the  old  modules. 

These  descriptions  were  specific  about  hardware  changes  but  general 
about  software  changes,  dealing  in  capability  only.  The  second  step 
was  to  change  the  appropriate  Functional  Operational  Specifications 
(FOS)  to  describe  the  required  changes  in  console  actions  and  operating 
procedures.  The  affected  Functional  Operational  Designs  (FOD)  were 
also  modified  at  this  time.  A contractor  was  then  asked  to  provide  peo- 
ple to  accomplish  the  program  design  and  coding  changes.  The  revised 
documents  were  used  to  direct  the  programming  effort.  The  program  was 
written,  tested  by  FCDSSA(SD)  using  simulated  F-14's,  and  then  taken  to 
the  Pacific  Missile  Range  (PMR)  test  facility  at  Pt.  Mugu  for  testing 
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with  the  actual  F-14.  After  6 months  of  testing,  a test  version  of  an 
operating  program  was  accepted  along  with  annotated  copies  of  the  FODTs 
and  other  documents.  This  completed  the  development  phase. 

The  production  phase  consisted  of  producing  a clean,  formal 
FOD  and  PDS  and  recompiling  the  program,  validating  it,  and  entering 
it  into  the  FCDSSA(SD)  control  library.  This  completed  the  production 
phase,  and  the  changed  modules  went  into  the  controlled  in-house  main- 
tenance phase. 

During  the  development  phase,  FCDSSA  did  not  try  to  change 
the  details  of  implementation  by  requiring  structured  programming  or 
using  other  new  and  unproven  techniques.  FCDSSA  believed  that  struc- 
tured programming  could  be  efficient  in  off-line  support  programming, 
such  as  test  programs,  but  not  in  tactical  applications  programming 
updates  to  the  existing  NTDS  program  libraries.  In  general,  the  pro- 
grammers were  permitted  to  implement  the  functional  requirements  of  a 
subprogram  in  any  way  they  chose,  within  the  limitations  imposed  by  the 
executive  and  language  standards  as  specified  in  the  FCDSSA(SD)  Program 
Production  Handbook,  The  acceptance  of  a program  by  FCDSSA(SD)  is 
based  on  its  performance  to  the  operational  function  requirements  and 
not  its  particular  coding  sequence.  Core  and  time  budgets  are  con- 
straints applied  in  the  SOD;  within  these  constraints  and  those  of  the 
compiler  and  library  GFE  and  the  module  interface  standards  (IMIC) , pro- 
gramming innovation  and  reliability  are  encouraged  and  evaluated  for 
contractor  fee  award,  but  not  mandated. 


5.5  SOFTWARE  VALIDATION  AND  INTEGRATION 

5.5.1  Validation  and  Integration  Approach 

The  primary  objective  of  validation  and  integration  at 
FCDSSA(SD)  is  to  verify  that  the  software  produced  satisfies  the  func- 
tional requirements  specified  by  the  FOD.  The  process  consists  of  inte- 
grating the  software  into  the  operational  program  and  testing  the  pro- 
gram functions  against  the  actions  specified  in  the  particular  FOD.  The 
design  of  the  software  is  not  considered  during  the  functional  valida- 
tion process,  having  been  accepted  at  the  program  level  during  instru- 
mented program  acceptance  tests  with  the  GFE  executive  and  IMIC  stan- 
dards given. 

Testing  of  the  software  against  the  FOD  consists  of  validating 
that  each  operator  function  is  performed  correctly.  Test  inputs  consist 
of  those  expected  during  normal  operation;  they  also  include  parameter 
out-of-range  conditions,  as  all  software  is  designed  to  check  each 
parameter  for  the  appropriate  range  of  values  in  the  peripheral  input 
tests  of  a given  program. 
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Functional  validation  is  restricted  basically  to  testing 
against  the  FOD;  as  long  as  the  FOD  is  satisfied,  later  changes,  if  any, 
are  made  onboard  the  ship.  It  is  economical  to  verify  the  FOD  at  the 
FCDSSA(SD)  facility  and  to  make  any  unspecified  changes  during  ship- 
board integration. 

5.5.2  Software  Validation  and  Integration  Procedures 

FCDSSA  has  an  extensive  test  and  validation  facility,  with 
capabilities  for  scenario  generation,  live  mock-up  operation,  periph- 
eral simulation,  and  nonreal-t ime  and  real-time  input  generation  from 
operational  consoles  and  data  links.  The  colocation  of  FCDSSA(SD)  with 
the  training  facility  permits  sharing  equipment. 

Software  test  and  validation  is  accomplished  by  five  sequen- 
tial phases,  ranging  from  basic  debugging  by  the  contractor  to  real- 
time testing  of  the  integrated  software  system  in  an  operational  mock- 
up.  The  five  phases  and  a brief  description  of  each  are 

1.  Phase  1,  Compile  — debugging  of  the  compiled  program  only. 

2.  Phase  2,  Emulate  — debugging  using  a host  computer  emula- 
tor to  execute  the  program  in  SHARE-7  using  on-line  dedi- 
cated operational  computers. 

3 . Phase  3,  Dedicated  on-line  simulation  for  program  accep- 
tance — exercising  the  program  using  the  real  executive 
with  scripted  intermodule  messages  in  nonreal-time . 

4.  Phase  4,  Nonreal-time  function  and  system  test  — live 
mock-up  of  the  system  with  nonreal-time  program  execution 
of  live  scripted  console  actions  (simulated) . Console  in- 
puts are  scripted  while  parametric  inputs  are  tested  for 
out-of-range  conditions;  otherwise  no  variation  of  quanti- 
tative tests  are  performed. 

5.  Phase  5,  Real-time  system  test  — live  mock-up  of  the  sys- 
tem using  live  inputs,  as  available,  and  performance  of 
quantitative  tests  with  operators  from  a scenario  taken 
from  the  SOD  and  FOD.  The  user  manuals  are  validated  dur- 
ing this  exercise. 

Phases  1 and  2 are  debug  and  verification  procedures  performed 
by  the  contractor;  FCDSSA  receives  the  software  under  the  condition  that 
these  phases  are  completed.  Phase  3 consists  of  FCDSSA  utilizing  a 
UYK-7  and  two  USQ-20  computers  to  execute  the  software  under  control  of 
the  real  executive  with  scripted  simulated  intermodule  messages.  Cur- 
rently Phase  3 support  software  is  being  expanded.  Phase  4 currently  is 
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the  function  test  phase  at  which  initial  validation  of  the  software 
capability  by  FCDSSA  occurs.  Phase  5 is  the  final  test  of  the  software 
performed  in  live  mock-ups  at  the  FCDSSA  facility.  Live  inputs  are 
used  when  the  required  equipment  is  made  available  at  the  facility  be- 
ing shared  with  training.  If  the  equipment  is  not  available,  its  opera- 
tion is  either  simulated,  or  the  necessary  portions  of  Phase  5 testing 
are  performed  onboard  the  ship  when  the  equipment  is  installed  and  pro- 
gram delivery  and  onboard  training  is  being  conducted  by  FCDSSA(SD). 

Plans  for  the  future  include  increased  use  and  improvement  of 
Phase  3.  It  is  intended  that  Phase  3 be  the  primary  validation  through 
which  FCDSSA  will  accept  or  reject  the  modular  software,  rather  than 

on  Phase  4.  Phase  3 uses  the  real  executive  and  should  include 
quantitative  tests.  The  test  system  which  will  support  Phase  3 testing 
is  designated  the  "Multi-Module  Test  Tool"  (MMTT) . 

The  SHARE-7  operating  system  supports  test  Phases  1,  2,  and  3. 
SHARE-7  software  runs  currently  in  a UYK-7  computer.  Through  SHARE-7 , 
a program  can  be  compiled  and  the  emulator  called  to  execute  the  program 
(Phase  2).  The  process  consists  of  partitioning  the  UYK-7  or  running 
with  two  USQ-20  computers  dedicated  on-line,  depending  on  whether  the 
target  (ship)  has  UYK— 7's  or  USQ— 20Ts  and  on  the  degree  of  execution  re- 
quired. 


Computer  equipment  associated  with  validation  and  integration 
includes  six  groups  of  computers,  each  group  with  symbol  generator, 
video  simulators,  and  analog  input  generators.  In  general,  eight  com- 
puters are  required  to  simulate  a ship  mock-up,  four  for  the  object  pro- 
gram and  four  for  full  simulation.  The  ECMU  has  been  added  to  the 
simulation  facility,  and  it  released  two  or  three  of  the  simulation  com- 
puters. 


Table  5-5  summarizes  the  documentation  used  during  the  testing 
stage  (as  indicated  previously,  the  documents  are  described  in  more  de- 
tail in  FCDSSA  Instruction  5600. 1C). 

Once  the  software  is  in  testing,  it  may  be  changed,  when  re- 
quired, only  by  the  test  group  using  the  in-house  configuration  control 
system. 


5.6  SOFTWARE  ACQUISITION  MANAGEMENT  ORGANIZATION  AND  METHODS 

5.6.1  Management  Information 

The  acquisition  of  the  NTDS  program  for  the  CV  was  controlled 
by  FCDSSA  throughout  its  development,  production,  and  maintenance  phases. 
This  information  is  summarized  in  Table  5-6. 
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TABLE  5-5 

CV  NTDS  TESTING  DOCUMENTATION 


Document  Name 


Content 


Test  Plan  (TP) 


Identifies  the  program  to  be  tested 
for  quality  assurance  and  details  the 
schedule  of  milestones  for  the  test,  in- 
cluding simulations,  equipment,  and  per- 
sonnel requirements . 


Test  Specifica- 
tion (TS) 


Identifies  the  capabilities  or  program 
functions  to  be  tested  and  the  test 
environment  used* 


Test  Procedures 
(TPR) 


Describes  the  test  exercise  script  of 
events . 


Test  Report 


(TR) 


Describes 


the  observed  test  results. 


TABLE  5-6 

SOFTWARE  MANAGEMENT  INFORMATION,  CV  CLASS  SHIPS 


Program  Status 

Deployed 

Program  Manager 

FCDSSA(SD) 

System  Contractor 

None 

Software  Contractor 

Various  plus  in-house 

Type  of  Contract 

Level  of  effort  (tasks  as 
necessary) 

Maintenance  Agent 

FCDSSA(SD) 

Validation  Agent 

FCDSSA(SD) 

Integration  Agent 

FCDSSA(SD) 

Software  Deliverables 

Phased  program  version  and 
documentation  deliveries 
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5.6.2  Software  Contracting  Methods 

The  NTDS  program  for  the  CV,  as  for  all  software  at  FCDSSA, 
was  developed  at  FCDSSA,  using  in-house  personnel  to  generate  the  FOD 
and  level-of-ef f ort  contracting  and  in-house  personnel  to  generate  the 
program  design  and  code.  The  contractor  worked  at  the  FCDSSA  facility, 
which  provided  all  the  necessary  equipment  and  support  software.  In 
FCDSSA1 s 15  years  of  experience,  the  results  of  this  type  of  contract- 
ing have  been  cost-effective.  These  results  can  be  contrasted  with 
programs  that  were  acquired  under  end-item  contracts,  with  only  the  pro- 
gram code  as  a deliverable.  The  end-item  contracting  resulted  in  ex- 
tremely costly  programs  that  were  difficult  to  maintain  and  unaccept- 
able to  the  users. 

FCDSSA  always  recommended  separately  funding  each  component 
task  in  the  software  acquisition  process,  with  each  task  tied  to  a de- 
liverable document.  Funding  of  each  task  would  be  contingent  on  the 
review  and  acceptance  of  the  previous  component  task.  The  documents 
generated  by  FCDSSA  in  each  phase  of  software  acquisition  have  been  de- 
scribed in  Tables  5-3,  5-4,  and  5-5.  This  system  of  documents  is  thus 
used  as  a basic  management  tool,  providing  technically  competent  in- 
house  personnel  with  a vehicle  to  direct  and  control  the  effort  continu- 
ously at  the  funding,  schedule,  and  technical  performance  level.  The 
Fleet  Officers  representing  the  user  permit  the  FCDSSA  effort  to  be 
effective  as  well  as  cost-efficient. 

5.6.3  Test  and  Evaluation  Organization  Structure 

The  Test  Department  handles  Phases  4 and  5 (refer  to  Section 
5.5.2)  of  software  validation  and  integration,  while  the  production  de- 
partment handles  Phases  1,  2,  and  3.  There  are  five  divisions  within 
the  Test  Department;  basically,  two  provide  test  support  and  one  each 
provides  configuration  control,  delivery,  and  peripheral  device  diagnos- 
tics. The  five  divisions  are 

1.  Change  Control 

2.  Evaluation  and  Analysis 

3.  Simulation  and  Test  Support 

4.  System  Test  and  Delivery 

5.  Diagnostics 

The  Evaluation  and  Analysis  division  as  well  as  the  production  depart- 
ment uses  Phase  3 testing.  A large  part  of  testing  at  this  level  con- 
sists of  hardware/ software  integration,  i.e.,  interface  testing,  timing, 
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and  the  evaluation  of  the  software  operating  with  the  hardware.  The 
Simulation  and  Test  Support  division  supports  Phase  4 testing  (nonreal- 
time, mock-up).  The  System  Test  and  Delivery  division  performs  Phase  5 
testing  (real-time  system  test)  and  concludes  at  sea  on-board.  The 
FCDSSA  organization  separates  function  testing  from  system  testing  by 
department.  The  Diagnostics  division  provides  all  necessary  diagnos- 
tics for  device  and  peripheral  checkout  and  testing  and  on-line  opera- 
tional program  exercises  prior  to  delivery  and  handover. 

5.6.4  Management  Findings 

Each  phase  of  the  NTDS  program  for  the  CV  has  gone  through 
three  distinct  life-cycle  stages:  development,  production,  and  mainte- 

nance. FCDSSA  believes  that  all  software  acquisition  should  include 
provisions  for  each  of  these  stages.  Each  stage  has  different  require- 
ments and  goals,  and  they  should  not  be  combined,  but  the  ultimate  user 
should  be  in  control  from  the  beginning,  and  he  should  be  the  sole 
agent  for  declaring  the  software  completed. 

FCDSSA  considers  that  in  all  software  acquisition  efforts  the 
ultimate  user  (or  his  designated  agent)  should  direct  all  three  stages 
of  software  and  should  have  technical,  fiscal,  and  managerial  control 
over  it.  The  ultimate  user  is  the  Navy  office  that  generates  the  re- 
quirement for  the  software.  The  users  fall  into  the  three  categories 
of  Combat  Direction  Systems  (CDS),  weapon  or  sensor  control  systems,  and 
automatic  data  processing  or  management  information  systems.  FCDSSA 
has  responsibility  for  some  examples  of  all  three  cases,  but  primarily 
the  first  (CDS).  The  CV  program  and  other  programs  that  were  developed 
under  FCDSSA  control  resulted  in  maintainable  programs  that  met  the  func- 
tional requirements  written  by  FCDSSA,  since  they  were  the  users.  On 
the  other  hand,  the  programs  that  were  developed  by  NAVMAT  contractors 
and  then  turned  over  to  FCDSSA  for  maintenance  were  always  more  costly 
to  develop  and  difficult  to  maintain,  because  the  user  was  not  considered 
in  the  early  stages  of  development.  Only  the  user  is  aware  of  the  real 
functional  requirements  of  the  system.  He  is  aware  of  the  documentation 
and  standardization  requirements  that  are  necessary  to  operate  and  main- 
tain the  software.  He  is  also  aware  of  the  facilities  available  for 
maintenance.  Therefore,  FCDSSA  believes  that  the  user  is  the  best 
agency  to  make  system  trade-offs  based  on  life-cycle  costs.  These 
costs  should  not  be  partitioned  among  various  Navy  sponsors  because 
this  would  prevent  making  these  trade-offs,  the  lack  of  which  has  re- 
sulted in  the  costly  and  unusable  examples  so  frequently  cited. 


5.7  OPERATIONAL  SOFTWARE  MAINTENANCE 

FCDSSA(SD)  has  had  the  responsibility  for  developing  and  main- 
taining all  NTDS  CDS  software  for  the  Pacific  fleet  since  1961.  Since 
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the  programs  are  both  produced  and  maintained  by  FCDSSA(SD) , there  is 
no  interorganizational  transfer  from  production  to  maintenance,  and 
therefore  no  cost  or  coordination  required  to  achieve  it. 

The  SINS  program  and  the  SPN-42  program  were  not  produced  and 
are  not  maintained  by  FCDSSA(SD).  No  problems  have  been  experienced 
with  either  of  these  systems  when  interfacing  to  the  NTDS , and  the  "user 
control”  dictum  is  successful  in  these  examples  as  well. 

The  maintenance  phase  consists  of  making  appropriate  modifi- 
cations and  additions  to  update  the  program  first  generated  in  the  pro- 
duction phase.  This  task  was  made  simple  at  FCDSSA  because  the  stan- 
dards and  documentation  used  by  the  development  and  production  phase 
were  designed  with  life-cycle  maintenance  in  mind.  Table  5-7  shows  the 
documentation  that  is  essential  during  operational  maintenance  of  CDS 
software . 


TABLE  5-7 

CV  NTDS  OPERATIONAL  MAINTENANCE  DOCUMENTATION  (User  Narrative  Group) 


Document  Name 


Computer  Operator 
Manual  (COM) 


Content 


s 


Describes  control  requirements  and  operating  pro- 
cedures necessary  to  successfully  initiate,  run, 
and  terminate  the  subject  system.  Also  describes 
diagnostic  or  maintenance  programs  in  support  of 
the  operational  program. 


Program  Design 
Manual  (PDM) 


Provides  documentation  for  the  computer  user  of 
the  program  structure  and  procedures  for  adding, 
modifying,  or  deleting  portions  of  the  program. 


Command  and  Staff 
Manual  (CSM) 


Provides  senior  officers,  operation  planners,  and 
all  TDS  operational  personnel  with  a basic,  non- 
technical description  of  the  data  system  program 
capabilities. 


System  Operator 
Manual  (SOM) 


Provides  a single  reference  for  individual  opera- 
tor training  and  combat  station  function,  in  suffi- 
cient detail  that  no  other  user  document  is  neces- 
sary. Also  serves  as  a handbook  for  trained  opera- 
tors . 
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5.7.1  Changes 

Each  particular  CV  program  is  designated  by  a model  and  phase 
number,  and  a ship  number.  A model  change  involves  a change  in  Link  11 
message  formats.  The  program  can  also  be  restructured  when  a model 
change  occurs.  A phase  change  typically  occurs  every  2 years  and  in- 
corporates into  the  program  all  patches  and  minor  changes  that  have 
accumulated  in  that  time  but  does  not  restructure  the  program. 

5.7.2  Trouble  Reports 

Trouble  reports  onboard  ship  occur  at  a rate  of  about  one  per 
week  for  the  first  month  of  a newly  installed  program.  The  source  of 
troubles,  in  the  vast  majority  of  reports,  is  the  hardware  or  misinter- 
pretation of  the  user  documentation.  On-board  program  patches  to  suit 
particular  ship’s  company  are  encouraged,  provided  such  patches  are  sent 
to  FCDSSA  for  the  record.  An  unpatched  copy  of  the  program  as  delivered 

is  secured  by  the  ship’s  officers  before  the  delivery  team  leaves,  so 

that  any  ship  problems  can  be  duplicated  at  FCDSSA  for  analysis  and  cor- 
rection. 


5.8  HIGHLIGHTS 

Software  breadboarding  was  used  extensively  in  the  develop- 
ment of  the  F-14  capability  in  the  CV  program.  FCDSSA(SD)  recommends 
this  in  all  new  programs,  to  prevent  redesign  and  slipped  schedules. 

(MP1) 

FCDSSA(SD)  shows  cost-effective  results  with  its  policy  of  in- 
house  development  using  level-of-ef f ort  contracting.  FCDSSA  personnel 
cite  programs  acquired  under  end-item  contracts,  with  the  program  code 
as  a deliverable,  that  have  resulted  in  costly  programs  that  were  diffi- 
cult to  maintain  due  to  design  or  documentation  incompatibility  with  the 
FCDSSA  facility  and  procedures  since  FCDSSA  contracts  for  a software 
capability  rather  than  a computer  program.  Separate  funding  is  recom- 
mended for  each  task  in  the  software  acquisition  process,  with  each  task 
tied  to  a deliverable  document.  Funding  of  each  task  would  be  contin- 
gent on  the  review  and  acceptance  of  the  previous  task.  (MP3,SE3) 

In  the  development  of  the  CV  NTDS  program,  FCDSSA(SD)  used  a 
sequence  of  milestones  through  the  analysis,  design  implementation,  in- 
tegration, test,  and  review  process.  Each  milestone  was  associated 
with  a specific  deliverable  document  or  program,  and  each  was  separately 
evaluated  and  award  fee  paid  accordingly.  In-house  capability  is  re- 
tained as  a back-up  in  the  event  of  contractor  failure,  but  since  small 
components  are  contracted,  no  catastrophic  failure  can  occur.  (API) 
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FCDSSA(SD)  uses  support  tools  and  facilities  and  periodically 
updates  its  support  software.  The  most  recent  operating  system,  desig- 
nated SHARE-7,  operates  in  a UYK-7  computer  and  contains  compilers, 
host-computer  emulators,  and  debug  aids.  SHARE-7  is  also  used  during 
the  first  phase  of  software  validation  and  integration  development  at 
the  program  level.  (IP1) 

FCDSSA(SD)  has  an  extensive  test  and  integration  facility 
which  it  shares  with  training.  It  provides  capability  for  live  mock-up 
of  systems  and  software  under  test.  There  are  provisions  for  nonreal- 
time and  real-time  operation,  peripheral  simulation,  operator  input  or 
simulated  operator  input,  and  use  of  operational  systems  hardware.  The 
FCDSSA(SD)  Test  Department  provides  test  support,  configuration  control, 
delivery,  and  diagnostics.  (IF3) 

FCDSSA(SD)  has  acted  as  an  agent  for  the  NAVMAT  Program  Mana- 
ger in  some  software  acquisition.  FCDSSA  personnel  cited  their  knowl- 
egdge  of  operational  requirements  and  believe  it  to  be  essential  to  de- 
veloping an  effective  CDS  program.  They  were  able  to  make  tradeoffs 
based  on  total  life-cycle  costs  because  of  their  awareness  of  the  total 
requirements.  They  strongly  recommend  having  a user  agent  for  the  Pro- 
gram Manager  involved  throughout  any  Weapon  Systems  software  acquisition 
process.  (MS2) 

Since  FCDSSA(SD)  is  both  the  developer  and  the  operational 
support  agent,  there  is  no  transfer  or  duplication  of  either  support 
software  or  of  test  and  integration  facilities.  No  cost  or  coordination 
is  required.  (MS3) 
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6.  AEGIS  WEAPON  SYSTEM 


6.1  GENERAL  SYSTEM  DESCRIPTION 

The  AEGIS  Weapon  System  is  a fast-reaction,  high-performance 
antiair  warfare  (AAW)  system  that  directs  the  Standard  Missile  against 
air  and  surface  targets.  It  is  an  integrated  shipboard  detection,  com- 
mand, and  weapon  control  system  that  is  being  engineered  for  installa- 
tion in  a wide  variety  of  ship  classes. 

The  AEGIS  mission  as  a large-scale  automatic  system  will  be  to 
provide  the  Fleet  with  a wide  area  surface-to-air  and  surface-to-surface 
defense  through  the  1980 Ts  and  beyond,  by  countering  aircraft,  antiship 
missiles,  and  launching  platforms.  When  used  with  long-range  surface- 
to-surface  cruise  missiles  and  extended  range  surface-to-air  missiles, 
the  system  will,  in  addition,  provide  the  Navy  with  a major  offensive 
surface  strike  capability. 

AEGIS  system  development  includes  construction  of  two  Engineer- 
ing Development  Models  (EDMf  s)  prior  to  construction  of  the  first  opera- 
tional ship.  The  first  development  model  (EDM— 1)  has  been  constructed 
and  is  currently  serving  aboard  the  USS  Norton  Sound  as  a test  bed.  The 
EDM-1  system  is  a limited,  performance  system  intended  to  provide  verifi- 
cation of  critical  AEGIS  capabilities. 

The  second  development  model  (EDM-3C)  will  be  installed  in  the 
land-based  Combat  System  Engineering  Development  Site  (CSEDS)  as  a pro- 
totype of  the  operational  system.  EDM-3C  will  provide  verification  of 
system  engineering,  interfaces,  ship  design  support,  and  operational  com- 
puter programming. 

The  major  elements  of  the  AEGIS  Weapon  System  are  a multifunc- 
tion phase— phase  array  radar,  weapon  control  and  fire  control  systems, 
missile,  launching  system,  command  and  decision  system,  and  operational 
readiness  test  system. 

The  combat  system  for  an  operational  AEGIS  ship  will  be  a 
federation  of  the  AEGIS  Weapon  System  with  complementary  AAW  systems, 
antisubmarine  warfare  (ASW)  systems,  and  Strike  weapons.  Variations 
in  system  configuration  will  allow  system  adaptation  to  a variety  of 
cruiser  and  destroyer  class  ships. 

6.1.1  AEGIS  Acquisition  History 

Requirements  and  conceptual  definition  for  an  Advanced  Surface 
Missile  System  were  derived  during  an  intensive  Navy/industry  study  con- 
ducted in  1963  under  the  direction  of  Rear  Admiral  F.  S.  Withington  (Ret.). 
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APL/JHU  assisted  the  Navy  in  the  conceptual  design  of  the  AEGIS  system, 
addressing  special  effort  to  the  more  difficult  technical  requirements. 
Design,  development,  and  demonstration  of  the  essential  elements  of 
the  multifunction  array  radar  were  accomplished  at  APL  and  provided  a 
firm  basis  for  a Full  Scale  Development  of  this  new  radar.  In  April 
1968,  Development  Concept  Paper  16  was  signed  by  the  Secretary  of  De- 
fense, and  DSARC  I approval  was  given  for  initiation  of  Contract  Defi- 
nition. In  1969,  following  competitive  proposal  submissions  by  Boeing, 
General  Dynamics,  and  RCA,  a contract  was  awarded  to  RCA  for  the  Engi- 
neering Development  of  the  AEGIS  Weapon  System. 

Program  milestones  A and  B for  Preliminary  Design  and  Criti- 
cal Design  Reviews  (PDR1 s and  CDR*  s)  were  completed  on  schedule,  and 
in  October  1973  completion  of  land-based  testing  at  the  RCA  plant  sig- 
nalled completion  of  milestone  C. 

During  the  initial  engineering  phase,  program  decisions  were 
made  to  develop  a functionally  modular  computer  program  and  provide  a 
Tactical  Executive  Program  structured  for  AEGIS.  The  specifications 
and  planning  reflected  strong  emphasis  on  the  software  acquisition  pro- 
curements . 


Installation  and  tests  at  sea  aboard  USS  Norton  Sound  have 
been  successful  and  have  generally  supported  program  decisions  made 
prior  to  and  during  the  design  reviews. 

In  June  1974,  DSARC  IIB  endorsed  the  program  and  supported  ac- 
quisition of  the  AEGIS  system.  Subsequent  planning  has  concentrated  on 
the  selection  and  approval  of  AEGIS  ship  classes  and  on  the  detailed 
definition  of  the  CSEDS. 

6.1.2  Baseline  System  Configuration 

The  major  elements  and  operation  of  the  AEGIS  Weapon  System 
are  represented  in  Fig.  6-1. 

The  multifunction  array  radar,  AN/SPY-1,  conducts  area  search, 
automatic  target  detection  and  tracking,  precision  tracking  of  targets 
selected  for  engagement , and  midcourse  command  guidance  communication 
with  the  Standard  Missile  (SM-2).  The  complex  operations  of  this  radar 
are  controlled  by  a four-bay  memory-shared  suite  of  AN/UYK-7  computers, 
the  current  standard  computer  for  new  surface  tactical  systems. 

An  identical  four-bay  AN/UYK-7  configuration  is  used  in  the 
Command  and  Decision  System  (C&DS)  Mk  1 to  provide  tactical  decision 
support,  operator  interfaces,  and  data  link  with  other  units,  and,  as 
shown  later,  to  interface  with  other  sources  of  tactical  data. 
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Fig.  6-1  AEGIS  Weapon  System,  Mk  7 
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A third  identical  AN/UYK-7  suite  is  used  in  the  Weapon  Control 
System  (WCS)  Mk  1 to  provide  weapon  engagement  assessment,  scheduling, 
and  control. 

The  above  three  AN/UYK-7  suites  are  supported  by  a disk  memory, 
available  to  all  suites  through  a multiplex  unit,  that  contains  contin- 
gency computer  programs  and  training  computer  programs.  The  disk  also 
contains  about  2 million  words  of  overlay  Operational  Readiness  Test  Sys- 
tem (ORTS)  Mk  1 computer  programs  and  fault  isolation  data.  The  central 
control  of  ORTS,  which  conducts  continuous  system  availability  testing 
and  provides  automatic  isolation  of  detected  faults  to  replaceable  unit 
level,  is  located  in  an  AN/UYK-20.  Control  of  specific  ORTS  testing  is 
allocated  among  all  three  AN/UYK-7  computer  groups. 

Precision  control  of  the  target  illuminators  is  allocated  to 
dedicated  AN/UYK-20  computers  in  the  Fire  Control  System  (FCS)  Mk  99. 

The  AN/UYK-20  is  the  current  standard  minicomputer  for  surface  tactical 
systems.  The  numbers  and  models  of  the  launching  system  and  the  direc- 
tor/illuminator are  adaptable  to  different  ship  configurations.  The  il- 
luminators are  slaved  to  AN/SPY-1  tracks. 

Operator  control  of  the  system  is  effected  through  general- 
purpose  consoles  of  the  AN/UYA-4  data  display  group.  Ten  to  eighteen 
consoles  may  be  used,  depending  on  ship  configuration  and  mission. 

These  are  supplemented  by  the  ORTS  test  and  monitor  console  and  by 
special-purpose  consoles  or  panels  within  interfacing  systems. 

6.1.3  Engineering  Development  Model  1 Configuration 

As  shown  in  Fig.  6-2,  EDM-1  is  a scaled  down  version  of  the 
baseline  system.  Each  of  the  primary  system  elements  is  implemented. 

The  system  is  limited  to  a single  AN/SPY-1  array  face,  one  launching 
system,  and  a single  illuminator  (with  tracking  capability  but  used  op- 
erationally only  in  the  slaved  mode) . 

[Changes  in  system  nomenclature  should  be  noted  for  under- 
standing the  following  discussions.  The  Command  and  Control  (C,C)  Sys- 
tem Mk  130  of  EDM-1  is  functionally  equivalent  to  the  C&DS  Mk  1 of  the 
AEGIS  baseline.  The  Weapon  Direction  System  (WDS)  Mk  12  of  EDM-1  is 
functionally  a subset  of  the  baseline  WCS  Mk  1,  but  includes  computa- 
tional functions  that  are  allocated  in  the  baseline  to  the  FCS  Mk  99.] 

EDM-1  uses  unit-computer  configurations  of  the  AN/UYK-7  com- 
puter rather  than  memory  sharing.  Two  components  support  control  of  the 
single  AN/SPY-1  array.  The  C,C  system  uses  a two-frame  AN/UYK-7  complex 
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with  one  central  processor  and  extended  memory.  The  WDS  uses  a single 
AN/UYK-7  computer  that  incorporates  launcher  and  illuminator  control  as 
well  as  weapon  scheduling. 

A simplified  version  of  the  ORTS  is  used  in  EDM-1,  covering 
fault  detection  in  the  AN/SPY-1  radar  and  a portion  of  the  WDS.  The 
EDM-1  ORTS  includes  the  central  test  and  monitor  console,  a monitor 
and  status  cabinet  in  the  radar  deckhouse,  data  acquisition  assemblies, 
and  associated  computer  programs. 

EDM-1  was  initially  designed  to  be  capable  of  target  engage- 
ment only  with  the  Standard  Missile-1  (RIM-66B-2) . Extensive  testing 
was  conducted  using  this  missile.  Subsequent  modifications  were  made 
to  the  system  and  the  computer  programs  to  enable  the  at-sea  testing  of 
Standard  Missile-2  (RIM-66C-1)  now  in  progress. 

Five  general-purpose  consoles  of  the  AN/UYA-4  data  display 
group  are  used  for  operator  control  of  EDM-1. 

6.1.4  AEGIS  Ship  Combat  System  Configurations 

To  provide  all  requisite  functions  for  a combatant  ship's 
Weapon  System,  the  AEGIS  Weapon  System  must  be  interfaced  with  addi- 
tional sensors,  communications,  weapons,  and  support  systems.  Some 
variation  in  these  interfaces  across  various  ship  installations  must  be 
expected  and  is  planned  for.  The  baseline  system  design  is  directed 
toward  a maximum  cruiser  configuration,  from  which  controlled  system 
variants  can  be  derived.  Figure  6-3  represents  the  design  baseline  for 
the  AEGIS  ship  combat  system. 

6. 1.4.1  Sensor  Systems 

The  AN/SPY-1  radar  is  the  primary  air  sensor  as  well  as  the 
primary  fire  control  radar  on  an  AEGIS  ship.  It  provides  rapid  horizon 
search  and  long-range  and  high-angle  coverage.  The  SPY-1  radar  reports 
data  on  a large  number  of  simultaneous  tracks.  Its  resources  are  adapt- 
able to  the  environment  and  the  tactical  situation. 

The  Identification  Friend  or  Foe  (IFF)  Interrogation  System 
AN/UPX-29  is  controlled  by  the  special-purpose  AN/UPX-24  digital  pro- 
cessor. It  can  be  directed  to  perform  rapid  secure-mode  interrogations. 
It  is  compatible  with  the  worldwide  IFF  military  and  commercial  coopera- 
tive identification  system. 

2D  Air  Search  and  Surface  Search  radars,  coupled  with  automatic 
detection  and  tracking  (ADT)  systems,  provide  auxiliary  detection  and 
tracking  capability.  Use  of  an  AN/UYK-20  minicomputer  in  each  ADT  system 
provides  a standard  interface  and  an  alternate  source  of  track  data. 
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Fig.  6-3  AEGIS  Ship  Combat  System 
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An  Electronic  Warfare  System  (EWS)  will  be  used  and  may  have  reac- 
tive capabilities  as  well  as  sensing.  The  expected  interface  is  with  a mini- 
computer via  standard  Naval  Tactical  Data  System  (NTDS)  channel. 

A Navigation  System  must  provide  both  ship’s  attitude  (roll,  pitch, 
heading)  and  ship!s  position  to  the  combat  system.  A system  is  under  study 
that  uses  a dedicated  AN/UYK-20  minicomputer  to  integrate  navigation  system 
elements  and  provide  continuous  updated  navigation  data  reports. 

The  sensor  control  function,  accomplished  within  the  C&DS , consists 
of  the  coordinated  use  of  the  ship’s  sensor  resources  and  the  merging  of 
available  data  into  a consolidated  track  file.  The  data  must  be  used  both  in 
tactical  decision  making  and  in  data-link  reporting  to  other  combatant  units. 

6. 1.4. 2 Tactical  Data  Links 

Full  exploitation  of  AEGIS  capabilities  in  a coordinated  task  force 
may  require  the  development  of  new  data  link  capabilities  for  weapons  control. 
Requirements  studies  on  this  subject  are  in  process.  For  current  design  plan- 
tactical  data  link  A (Link  11),  Model  IV,  is  adopted  as  a baseline.  A 
teletype  link  (Link  14)  capability  will  also  be  provided  for  communication 
with  non-Tactical  Data  System  (TDS)  units. 

The  links  dedicated  to  control  of  AAW  and  ASW  aircraft  (including 
Light  Airborne  Multipurpose  Platform  System  [LAMPS])  are  under  the  management 
of  the  WCS. 

The  data  links  are  digitally  controlled,  have  the  standard  NTDS  in- 
terface with  the  system  computers,  and  use  the  combat  system  Exterior  Commu- 
nication System  to  transmit  and  receive  signals. 

6.1. 4. 3 Weapons 

AEGIS  provides  the  primary  AAW  weapon,  Standard  Missile-2  (Medium 
Range),  which  acts  in  force  area  defense,  self-defense,  and  short-range  sur- 
face engagement  roles. 

Supplementing  the  AEGIS  air  defense  is  the  Close-in  Weapon  System 
(CIWS) , which  provides  a final  defense  against  penetrators  of  the  missile  en- 
velope. The  CIWS  is  a self-contained  system,  but  can  be  configured  to  accept 
target  designations  from  other  data  sources. 

ASW  capabilities  are  provided  by  the  LAMPS  helicopter,  the  AN/SQS- 
53A  sonar,  the  AN/SQR-19  towed  array,  and  the  Underwater  Weapon  System  (UWS) . 
LAMPS  is  both  a data  source  and  a weapon  delivery  platform  and  thus  has  inter- 
faces with  both  C&DS  and  WCS  computers.  The  AN/SQS-53A  and  AN/SQR-19  are  on- 
board sensors.  The  AN/SQS-53A  interfaces  with  the  Mk  116  to  provide  sonar 
tracks  to  WCS  and  C&DS  as  well  as  to  provide  Target  Motion  Analysis  (TMA) 
solutions  for  underwater  fire  control.  The  AN/SQR-19  provides  passive  track 
data  to  C&DS  via  voice.  The  UWS  is  controlled  by  the  Underwater  Fire  Control 
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System  Mk  116,  which  uses  a single-bay  AN/UYK-7  computer.  This  system  con- 
trols both  torpedo  launch  and  ASROC  missiles.  For  ASROC  launch,  the  AEGIS 
Mk  26  launching  system  is  switched  to  UWS  control. 

Strike  capabilities  are  provided  on  the  appropriate  ships  by  the 
Harpoon  Weapon  System  and  by  longer  range  tactical  cruise  missiles.  The  sys- 
tem baseline  provides  canister  launchers  for  these  missiles.  Harpoon  engage- 
ment is  controlled  by  a dedicated  computer  that  is  incorporated  in  the  Harpoon 

control  console.  The  cruise  missile  system  is  expected  to  have  a similar  dedi- 
cated  computer. 


Various  Gunfire  Control  System  (GFCS)  approaches  have  been  investi- 
gated for  the  control  of  8n/55  or  5l,/54  guns  in  both  air  and  surface  modes. 

The  baseline  is  the  GFCS  Mk  86,  which  uses  a one-bay  AN/UYK-7  computer  and 
three  special-purpose  control  consoles. 

6.1. 4. 4 Combat  System  Integration 

seen  i-n  the  previous  discussion,  the  systems  approach  has  been  to 
allocate  coordination  functions  to  the  AEGIS  C&DS  and  WCS,  but  to  distribute 
control  processes  to  dedicated  computers  within  the  various  weapon  and  sensor 

systems.  This  approach  is  expected  to  carry  a number  of  benefits,  among  which 
are 


1.  Standardization  of  interfaces; 

2.  Controlled  distribution  of  design  responsibility; 

3.  Use  of  existing  systems,  where  applicable,  with  minor  adaptation 
only;  and 

4.  Minimum  impact  on  the  system  design  from  adaptation  to  various 
ship  installations  or  incorporation  of  new  interfacing  systems. 

Standard  computers,  computer  peripherals,  support  computer  program- 
ming, and  operator  consoles  are  used  throughout  the  system,  with  exceptions 
being  made  where  an  existing  system  design  can  be  used  with  minimum  change. 
,5^5  ^fnn^01  lnterfaces  in  nearly  all  cases  use  the  digital  NTDS  standard 


Projected  Ship  System  Diagram 


Figure  6-4  represents  an  AEGIS  operational  ship 
shows  the  functional  relationships  among  system  elements, 
in  the  diagram  (e.g.,  Cl)  can  be  referenced  via  Table  6-1. 


configuration  and 
Any  given  computer 
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COMPUTER  SYSTEM  ARCHITECTURE 
Computer  Characteristics 

Table  6-1  details  the  computers,  gross  computer  characteris- 
tics, and  major  allocated  functions  for  a representative  AEGIS  opera- 
tional ship  configuration.  Unit  designations  (e.g.,  Cl)  are  keyed  to 
the  system  diagram,  Fig.  6-4.  In  addition  to  the  four  AEGIS  AN/UYK-7 
suites  and  illuminator  control  computers,  dedicated  computers  are  shown 
for  underwater  battery  fire  control,  the  ADT's  with  the  auxiliary  2D 
radars,  the  GFCS , and  LAMPS.  Additional  dedicated  computers  may  be 
found  embedded  within  the  systems  that  will  interface  with  AEGIS. 


6.2 

6.2.1 
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TABLE  6-1 

AEGIS  SHIP  COMPUTER  SUMMARY 


Unit 

Type 

Function 

Pro- 

cessors 

Memory 

Rl,  R2 , 
R3 , R4 

AN/UYK-7 
(32  bit , 
1.5  ys) 

Radar  control,  search 
scanning,  automatic  tar- 
get detection  and  track, 
communication  with  guided 
missiles 

4 

256k 

Cl,  C2, 
C3 , C4 

AN/UYK-7 
(32  bit, 
1.5  ys) 

Multisensor  data  correla- 
tion and  management,  iden- 
tification, threat  evalua- 
tion and  weapon  assignment, 
display  communications, 
surface  operations 

4 

256k 

Wl,  W2 , 
W3 , W4 

AN/UYK-7 
(32  bit, 
1.5  ys) 

Weapon  direction  and  fire 
control,  air  intercept  con- 
trol, ASW  support,  LAMPS 
support,  launcher  control 

4 

256k 

W5 

AN/UYK-20 
(16  bit, 
750  ns) 

Illuminator  control 

4 

64k  each 

R5 

AN/UYK-20 
(16  bit, 
750  ns) 

Auto  detection  and  track 
from  beacon  and  2D  digit- 
ized video  data 

2 

32k  each 

W6 

AN/UYK-7 
(32  bit, 
1.5  ys) 

Underwater  battery  fire 
control 

1 

48k 

W7 

AN/UYK-7 
(32  bit, 
1.5  ys) 

Gun  fire  control 

1 j 

48k 

W8 

AN/UYK-20 
(16  bit, 
750  ns) 

LAMPS  control 

1 

32k 

T1 

AN/UYK-20 
(16  bit , 
750  ns) 

ORTS 

1 

48k 

# Computer  peripherals  will  include:  two  (for  redundancy)  mass 

storage  disk  memories,  digital  system  clock,  magnetic  tape  units  for 
data  recording,  and  an  input/outout  (I/O)  console.  Provision  is  made 
for  centralized  computer  control  and  initialization  at  the  ORTS  test 
and  monitor  console.  In  addition,  a conversational  terminal  and  printer 
will  be  used  with  each  computer  suite  during  system  development. 
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Computer  resource  allocations  (throughput,  memory,  and  I/O 
channels)  have  been  made  within  the  TADSTAND-5  20%  reserve  require- 
ments. In  throughput  and  memory,  an  additional  reserve  of  20%  has 
been  retained  for  design  margin.  The  resource  allocations  include 
reservation  for  planned  "space  and  weight"  systems. 

6.2.2  General  Considerations 

AEGIS  has  moved  further  toward  full  computer  control  of 
Weapon  System  functions  than  previous  shipboard  systems.  Requirements 
allocated  to  the  system  computers  that  have  determined  the  configura- 
tion design  include 

1.  Automated  control  of  the  multifunction  array  radar  opera- 
tions in  a complex  hostile  environment  ; 

2.  Fully  automated  rapid  system  reaction  to  threats,  from 
detection  through  kill; 

3.  High  system  capacities  for  engagement  and  surveillance; 
and 

4.  Continuous  system  availability,  leading  to  continuous 
on-line  readiness  testing,  automatic  fault  isolation, 
and  rapid  computer  reconfiguration  in  the  event  of  com- 
puter or  program  faults. 

The  operational  system  is  designed  for  coordination  of  total 
combat  system  operations  as  well  as  the  control  of  the  basic  AEGIS  AAW 
mission  areas. 

Although  EDM-1  Is  a smaller  and  less  complex  system  than  the 
operational  AEGIS,  many  features  of  the  configurations  are  common,  in- 
cluding 

1. 

2. 


3. 


4. 


5. 


6. 


Use  of  the  standard  AN/UYK-7  computer; 

Use  of  disk  memory  for  operational  and  test  program  and 
data  loading; 

Use  of  an  electronic  switch  to  provide  multicomputer 
access  to  the  disk  memory; 

Use  of  a central  digital  clock  to  provide  a common  time 
reference  to  all  computers; 

Segmentation  of  the  computer  program  development  into 
functionally  identifiable  separate  programs;  and 

Use  of  a common  executive  program  in  all  segments. 
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6.2.3  EDM-1  Computer  System  Configuration 

For  the  first  AEGIS  engineering  model,  a conservative  unit- 
computer  approach  was  adopted.  As  shown  previously  (Fig.  6-2),  four 
AN/UYK-7  computers  are  used.  Two  of  these  control  the  AN/SPY- 1 radar, 
one  is  in  the  WDS,  and  the  fourth,  which  has  an  extended  memory,  is 
used  in  the  C,C  system. 

These  computers  use  the  basic  one-bay  AN/UYK-7  configuration, 
which  includes  one  central  processing  unit  (CPU) , three  16k  x 32  bit 
memory  units  (MU),  one  input/output  controller  (IOC),  an  input/output 
adapter  with  16  I/O  channels,  and  a power  supply  unit.  The  C,C  com- 
puter is  bus-connected  to  two  additional  MU's  in  an  adjacent  bay.  All 
communication  among  CPU's  is  by  means  of  MIL-STD-1397  intercomputer 
interface  channels,  under  IOC  control. 

Figure  6—5  shows  the  computer  configuration,  major  interfaces, 
and  computer  peripheral  units  employed. 

No  alternate  or  casualty  configurations  were  designed  for 

EDM-1. 

6*2.4  AEGIS  Baseline  Computer  Configuration 

The  AEGIS  operational  system  computer  baseline  has  been  de- 
veloped to  provide  projected  throughput,  memory,  and  communication 
capacities,  with  both  design  margin  and  delivery  reserves,  to  comply 
with  computer  standardization  directives  and  to  meet  system  availabil- 
ity requirements.  Major  changes  from  the  EDM-1  system  are 

1.  Growth  to  12  AN/UYK— 7 processors, 

2.  Use  of  memory  sharing,  in  a standard  four-bay  configura- 
tion, and 

3.  Use  of  AN/UYK-20  peripheral  processors. 

Projections  of  required  computer  capacity  have  been  made 
based  on  EDM-1  design  experience,  approved  system  requirements,  and 
examination  of  other  AN/UYK-7  combat  system  programs  such  as  the  DLGN- 
38  computer  programs. 

The  memory-shared  configuration  was  developed  to  satisfy  both 
performance  and  availability  considerations.  In  the  AN/SPY-1  control 
suite,  where  processing  throughput  is  at  a premium,  inter-CPU  communi- 
cation via  shared  memory  is  a significantly  smaller  load  than  via  I/O 
channels.  In  the  C&DS,  where  memory  space  is  at  a premium,  the  central 
track  data  files  can  be  shared  by  many  functions.  In  all  three  suites, 
the  shared-memory  configuration  enables  automatic  reaction  to  an  equip- 
ment failure  without  mechanical  switching. 
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Fig.  6-5  EDM-1  Computer  System  Configuration 
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Figure  6 6 shows  the  CPU,  IOC,  and  MU  interconnections  within 
a four-bay  suite.  In  the  figure,  physical  computer  bays  are  indicated 
by  shading.  A double-density  MU  (32k  x 32  bit)  is  indicated  by  a 
slashed  MU  box  with  two  MU  numbers. 


AN/UYK  7 MU  restrictions  do  not  allow  full  interconnectivity. 
There  is  a limit  of  eight  ports  to  a MU.  One  of  these  is  required  for 
IOC  use,  two  for  CPU  use  when  the  MU  contains  programs  to  be  executed. 
Only  one  MU  port  is  required  for  CPU  data-only  access.  This  configura- 
tion provides  the  full  256k  unambiguous  AN/UYK-7  memory  space.  It  is  a 
symmetrical  arrangement  allowing  use  of  one  three-bay  alternate-mode 
computer  program  design  in  event  of  any  one-bay  failure.  IOC  connection 
to  memory  allows  two  IOC's  access  to  all  memory,  for  master  and  alter- 
nate load  channels.  CPU-IOC  interconnections  are  restricted  initially 
to  those  within  a bay,  since  only  dedicated  CPU  tasking  is  planned.  If 
in  the  future  a change  is  made  to  multiprocessing,  provision  can  be  made 
to  connect  two  multiprocessing  pairs. 

The  casualty  approach  is  to  treat  any  failure  as  a full-bay 
failure,  place  that  bay  off-line  for  maintenance,  and  load  a three— bay 


Memory  units 


• Data  and  instruction 
O Data  only 
^Multiprocessing  only 


CPU's 


IOC's 


Fig.  66  Baseline  Computer  Suite  Architecture 
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alternate  program  from  disk.  To  maintain  communication  with  external 
devices,  two  I/O  channels  are  assigned  to  each  critical  device  and  an 
electronic  switch  is  required  at  the  device. 

A number  of  benefits  were  found  in  the  concept  of  a single 
configuration  of  the  AN/UYK-7,  including  simplified  operating  system, 
support  software,  and  configuration  control.  Since  a sensible  alloca- 
tion of  computational  functions  could  be  made  in  the  context  of  three 
standard  four-bay  suites,  this  configuration  was  adopted  as  a baseline. 

It  was  also  found  advantageous  to  channelize  the  precision 
control  of  the  target  illuminators  by  allocating  this  function  to  dedi- 
cated minicomputers.  One  minicomputer  is  allocated  to  each  illuminator 
director,  to  provide  redundancy  in  case  of  casualty.  This  allocation 
removed  a potential  overload  in  the  weapon  control  suite  and  gave  a con- 
figuration easily  adaptable  to  ships  with  varying  numbers  of  illumina- 
tor channels. 


6.3  COMPUTER  PROGRAM  ARCHITECTURE 

At  the  time  of  this  report,  the  computer  programs  for  AEGIS 
EDM-1  have  completed  design  and  test  and  have  been  extensively  exer- 
cised in  the  course  of  AEGIS  system  evaluation.  The  computer  programs 
for  AEGIS  EDM-3C  are  in  the  design  phase.  The  following  discussions 
will,  therefore,  describe  the  EDM-1  modular  design,  with  indication  of 
size  and  operating  relationships,  and  give  preliminary  estimates  of  the 
design  structure  for  the  expanded  EDM-3C  system. 

AEGIS  EDM-1  operational  computer  programs  include  the  common 
AEGIS  Tactical  Executive  Program  (ATEP)  and  programs  for  the  four  unit 
computers  in  the  system. 

The  AEGIS  EDM-3C  computer  programs  are  being  designed  for  op- 
* erational  use  in  the  first  AEGIS  ships.  These  programs  consist  of 

1.  AEGIS  Tactical  Executive  System  (ATES), 

2.  Programs  for  the  three  AN/UYK-7  computer  suites,  which 
are  elements  of  the  AN/SPY-1  radar,  WCS , and  C&DS , 

3.  Fire  control  computer  programs,  which  execute  in  the 
channelized  AN/UYK-20  computers  and  which  will  be  under 
control  of  the  standard  AN/UYK-20  Executive  Program, 
SDEX-20,  and 

4.  ORTS  programs,  which  are  allocated  among  the  three  AN/ 
UYK-7  computer  suites  and  an  AN/UYK-20. 
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Detailed  allocation  of  functions  to  computer  program  modules 
for  EDM-3C  is  still  in  the  developmental  stage.  Where  applicable,  this 
allocation  closely  resembles  EDM-1,  especially  in  the  radar  control  com- 
puters . 

6.3.1  AEGIS  Tactical  Executive  Program 

6. 3.1.1  EDM-1  AEGIS  Tactical  Executive  Program 

ATEP  is  the  computer  program  management  system  that  resides 
in  and  controls  the  processing  in  each  of  the  M/UYK-7  computers.  ATEP 
schedules  the  application  modules  and  controls  the  use  of  the  computer, 
memory  allocations,  and  assignment  of  programs  and  data  sets,  common 
service  routines,  and  standard  peripheral  devices.  ATEP  performs  vari- 
ous program  services  including  message  handling,  dynamic  storage  allo- 
cations, error  handling,  standard  peripheral  device  services,  and  util- 
ity services.  ATEP  interfaces  with  task  state  modules  by  a standard  set 
of  executive  service  requests  (ESR’s)  for  the  purpose  of  exchanging  data 
and  command  information. 

The  initial  version  of  the  ATEP  used  in  EDM-1  was  constrained 
to  control  of  unit  computers.  The  expanded  ATEP  now  under  development 
for  EDM-3C  is  described  more  fully  in  Section  6. 3. 1.2. 

6. 3. 1.2  EDM-3C  AEGIS  Tactical  Executive  System 

For  the  EDM-3C,  ATES  is  divided  into  two  component  programs, 
the  ATEP  Kernel  and  the  Application  Dependent  Executive  Program  (ADEP) . 
This  has  been  done  to  allow  for  installation  and  facility  tailorability 
and  simplification  in  management  and  development. 

The  ATEP  Kernel  provides  the  basic  control  mechanism  for  user 
modules  operating  in  the  AN/UYK-7 . It  operates  in  the  interrupt  state 
and  provides  centralized  services  that  are  application  independent,  such 
as  the  handling  of  interrupts,  the  scheduling  of  the  overall  systems 
operation,  the  apportionment  of  processing  resources  to  a task,  and  the 
management  of  I/O.  Other  application-oriented  executive  functions  such 
as  loading,  standard  peripheral-device  handlers,  utility  services,  and 
common  subroutines  may  be  added  as  ADEP T s . 


The  Kernel  is  designed  to  support  each  of  the  three  major  pro- 
cessing concepts  presently  used  in  the  AN/UYK-7  computer  (i.e.,  unipro- 
cessing, multiprocessing,  and  the  concept  of  multiple  CPU’s,  each  with 
its  own  executive  communicating  through  shared  memory). 

The  Kernel  is  tailorable.  There  is  provision  for  dropping  at 
compile  time  those  functions  not  required  for  the  particular  application. 
For  example,  in  a unicomputer  system  all  multiprocessing  and  shared- 
memory  features  (and  overhead)  can  be  dropped.  Table  sizes  can  also  be 
selected. 
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Also  tailorable  at  compile  time  and  at  load  time  is  the  choice 
of  the  ADEP,  including  the  choice  of  routines  to  control  the  standard 
computer  peripherals  (magnetic  tapes,  disk,  and  printers)  and  the  choice 
of  a program  loader.  Specific  AEGIS  application-oriented  functions  in- 
clude initialization  and  loading,  peripheral  device  processing,  utili- 
ties, data  recording,  error  processing,  intercomputer  communication, 
background  self-test,  system  clock  processing,  and  common  service  rou- 
tines . 


In  order  to  satisfy  the  broad  range  of  possible  configurations, 
system  architectures,  and  processing  requirements,  the  Kernel  is  con- 
structed in  modular  fashion.  Inherent  in  the  Kernel  are  the  scheduling, 
dispatching,  interrupt  processing,  and  I/O  control  services.  The  Kernel 
consists  of  the  following  entities: 

1.  Resident  Initialization  Function  — initializes  ATEP  tables 
and  dispatches  user  modules  at  their  initialization  en- 
trances . 

2.  Interrupt  Processing  Function  — receives  all  AN/UYK-7  com- 
puter interrupts  and  calls  the  appropriate  Kernel  or  ADEP 
routines. 

3.  Scheduling  .Function  — enters  all  module  scheduling  re- 
quests into  a priority-sequenced  queue.  Modules  may  be 
scheduled  upon  the  receipt  of  a request  from  another 
module,  or  periodically  after  a specified  interval  of  time, 
or  upon  the  receipt  of  an  I/O  interrupt. 

4.  Dispatching  Function  — selects  the  request  with  the  high- 
est priority  from  the  scheduling  queue  and  dispatches  this 
module  at  the  specified  one  of  seven  possible  entrances; 
it  also  provides  module  termination  services. 

5.  I/O  Processing  — provides  intercommunication  between  task- 
state  modules  and  their  associated  IOC  channel  programs. 

6.  Memory  Management  Function  — controls  the  assignment  of 
core  storage  that  can  be  dynamically  assigned. 

7.  Message  Processing  Function  — provides  for  the  transmis- 
sion of  messages  from  module  to  module(s). 

8.  Fault  Processing  Function  — makes  up  a data  packet  concern- 
ing any  discovered  fault  and  passes  it  on  to  an  appropriate 
error  processor.  Manages  automatic  reload  and  reconfigura- 
tion. 

9.  Utility  Interface  Function  — provides  special  features  that 
enhance  debugging  and  measurement  of  system  performance. 
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The  executive  also  supports  use  by  a module  of  the  following  additional 
types  of  program  and  data-set  core  areas: 

1.  Common  service  routines  that  are  accessible  to  modules 
for  CPU  execution. 

2.  Common  data  areas  in  core  that  may  be  accessed  by  two  or 
more  modules. 

3.  Temporary  storage  areas  that  are  assigned  upon  request 
to  a module  by  the  Kernel. 

4.  Scratch  pad. 

A computer  program  that  runs  under  the  control  of  ATEP  con- 
tains the  following  components: 

1.  Kernel 

2.  Selected  ADEP  routines 

3.  User-supplied  program  tables 

4.  User-defined  executive  tables 

The  computer  program,  containing  all  of  the  above  elements  is  initially 
loaded  via  the  Initialization  and  Loading  function  of  ADEP,  which  then 
gives  control  to  the  Kernel. 

The  primary  element  in  the  operation  of  the  computer  is  the 
Kernel  priority  scheduling  queue  which  contains  a list  in  priority  se- 
quence of  those  program  modules  to  be  dispatched  (i.e. , gives  control 
of  the  CPU  to  carry  out  some  task). 

A task-state  module  turns  over  control  to  the  Kernel  via 
ESRfs.  An  ESR  call  will  cause  an  interrupt  to  the  CPU,  and  the  Kernel 
will  then  carry  out  the  particular  executive  service  requested  by  the 
module  before  returning  to  task  state.  Typical  services  to  be  carried 
out  by  the  Kernel  include:  assigning  a temporary  storage  data  area  to 

the  module,  scheduling  another  module  as  a successor,  sending  a mes- 
sage to  another  module,  and  initiating  a specified  I/O  command  to  an 
IOC. 

ATEP  currently  provides  100  different  ESRTs  and  19  Common  Ser- 
vice routines.  ATEP  Kernel  use  of  computer  memory  ranges  from  2500  to 
5000  words,  depending  on  configuration.  A four-bay  ATES , including 
four  copies  of  the  Kernel  and  ADEP  elements,  is  estimated  at  35,800 
words.  ATEP  use  of  computer  CPU  time  is  estimated  at  about  10  to  15% 
of  each  active  CPU. 


6-19 


THE  JOHNS  HOPKINS  UNIVERSITY 

APPLIED  PHYSICS  LABORATORY 

laurel,  Maryland 


6.3.2  AN/SPY-1  Control  Computer  Program 

6.3.2. 1 EDM-1  AN/SPY-1  Control  Computer  Program 

The  program  is  divided  between  two  computers.  Figure  6-7 
shows  a simplified  schematic  of  the  radar  control  program.  The  squares 
represent  modules  with  major  data  flow  shown  by  the  lines  linking  the 
modules.  The  primary  flow  of  radar  control  orders  and  data  is  repre- 
sented by  the  heavier  lines. 

Computer  1,  generally  referred  to  as  the  Control  Computer, 
has  as  its  primary  functions  radar  scheduling,  track  processing,  and 
search  management.  Support  functions  include  console  management  for 
the  radar  control  console,  WDS,  and  C,C  interfacing,  and  radar  initiali- 
zation; secondary  support  includes  background  self-test  and  load  evalua- 
tion functions.  Computer  2,  generally  referred  to  as  the  Face  Computer, 
has  as  its  primary  functions  output  control  and  radar  return  processing. 
Support  functions  are  gyro  position  processing  and  background  self-test. 
The  Face  Computer fs  primary  task  is  interfacing  to  the  AN/SPY-1  Radar 
Signal  Processor. 

Table  6-2  lists  the  major  functions  performed  by  each  of  the 
AN/SPY-1  computer  program  modules  and  indicates  their  use  of  computer 
time  and  core.  Total  program  core  use  is  42,600  32  bit  words.  The  pro- 
gram uses  about  119%  of  an  AN/UYK-7  CPU.  Module  time  statistics  are 
scenario  dependent;  the  values  vary  with  the  number  of  radar  dwells 
scheduled  and  radar  returns  processed.  Values  presented  in  Table  6-2 
are  for  a typical  radar  environment. 

6. 3. 2. 2 EDM-3 C AN/SPY-1A  Control  Computer  Program 

The  computer  program  design  projected  for  EDM-3C  is  similar 
in  structure  to  that  of  EDM-1  but  expanded  in  scope  to  support  four 
array  faces  and  additional  radar  functions.  The  program  uses  four  AN/ 
UYK-7  CPU's,  which  communicate  via  shared  memory. 

Figure  6-8  shows  the  allocation  of  the  major  processing  func- 
tions to  CPU's  and  the  principal  flow  of  data.  An  estimated  use  of  com- 
puter memory  is  120,000  words.  Processing  time  is  strongly  dependent  on 
the  scheduling  of  radar  events  and  the  number  of  targets  detected.  The 
system  design  has  attempted  to  strike  a balance  among  transmitter  power, 
radar  signal  receive  time,  and  computer  processing  resources.  An  esti- 
mate of  260%  of  a single  CPU  throughput  is  given  for  a typical  heavily 
loaded  case. 

6.3.3  Weapon  Control  Computer  Program 

6.3.3. 1 EDM-1  Weapon  Direction  Computer  Program 

This  computer  program  controls  the  actual  engagements  and, 
therefore,  interfaces  with  and  controls  the  illuminators,  launcher,  and 
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Fig.  6-7  EDM-1  AN/SPY-1  Control  Computer  Program  Module  Diagram 
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TABLE  6-2 

AN/SPY-1  CONTROL  MODULE  FUNCTIONS 


Module 

Core 

Time 
(%  of 
one  CPU) 

Search  Management  Module:  Generates  surveillance 

beam  requests. 

3,300 

1 

Radar  Scheduling  Module:  Schedules  radar  events 

such  that  search  and  track  requirements  are 
maintained. 

2,000 

24 

Track  Processing  Module:  Maintains  track  stores; 

correlates  search  detections  with  existing 
tracks.  Initiates  requests  for  tracking  beams. 

2,700 

20 

Track  Association  Module:  Identifies  track  re- 

dundancies and  eliminates  stale  tracks. 

400 

— 

Switch  Action  Module:  Interfaces  between  Radar 

Control  Console  and  AN/SPY-1  Control  program. 
Implements  operator  actions. 

6,000 

4 

Load  Evaluation  Module:  Computes  radar  and  com- 

puter processing  loads. 

200 

— 

C,C  User  Services  Module:  Transfers  and  routes 

AN/SPY- 1 Control/C, C intersegment  messages. 

900 

— 

Weapon  Control  User  Services  Module:  Transfers 

and  routes  AN/SPY-1  Control/WDS  intersegment 
messages. 

900 

Historical  Recording  "A"  Module:  Records  data 

from  AN/SPY-1  Control  Computer  1. 

400 

— 

Radar  Initialization  Module:  Controls  up  and 

down  sequence  of  AN/SPY-1  radar. 

1,200 

— 

Background  Self-Test  nAM  Module:  Performs  self- 

testing during  CPU  "idle  time"  for  AN/SPY-1 
Control  Computer  1. 

300 

“ 

Historical  Recording  "B"  Module:  Records  data 

from  AN/SPY-1  Control  Computer  2. 

400 

— 

Output  Formatting  and  Control  Module:  Computes 

beam  stabilization  parameters;  interfaces 
between  AN/SPY-1  Control  and  Radar  Signal. 

2,700 

40 

Radar  Return  Processing  Module:  Interfaces  be- 

tween Radar  Signal  Processor  and  AN/SPY-1 
Control;  converts  coordinate  systems. 

2,900 

28 

Gyro  Update  Module:  Smoothes  and  extrapolates 

gyro  data;  handles  gyro  to  AN/SPY-1  Control 
interface;  computes  array  face  limits. 

1,200 

2 

Background  Self-Test  ’’B”  Module:  Performs  self- 

testing during  CPU  "idle  time”  for  AN/SPY-1 
Control  Computer  2. 

System  Clock  Module:  Sets  time  of  day  reference. 

500 

ATEP 

8,000 

— 

Common  Data 

4,500 

— 

Common  Services 

1,800 

— 
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Fig.  6-8  EDM-3C  AN/SPY-1  Computer  Program  Module  Diagram 
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missiles  through  the  WDS.  Functions  of  this  computer  program  include 
target  engageability  assessment,  scheduling  of  engagements,  control  of 
missile  loading,  launcher  positioning,  missile  preset,  and  the  launch 
process,  and  control  of  illuminator  scheduling  and  positioning  for  mis- 
sile guidance.  Figure  6-9  is  a simplified  block  diagram  of  the  EDM-1 
WDS  computer  program.  Table  6-3  lists  the  major  functions  performed  by 
the  WDS  computer  program  modules  and  their  use  of  computer  time  and 
core.  Total  program  core  use  is  46,600  words;  the  program  uses  about 
69%  of  an  AN/UYK-7  CPU  under  a typical  engagement  load. 


TABLE  6-3 

EDM-1  WEAPON  DIRECTION  SYSTEM  MODULE  FUNCTIONS 


Module 

Core 

Time 
(X  of 
one  CPU) 

Target  Scheduling  Module:  Processes  messages  from 

C,C  segment;  initiates  all  WDS  assignments. 

3,100 

2.0 

AN/SPY-1  Control  Input  Module:  Processes  track 

data  messages  from  AN/SPY-1  Control  segment; 
performs  track  smoothing. 

300 

0.2 

Engageability  Module:  Computes  target  engageabil- 

ity parameters. 

200 

C,C  Output  Module:  Processes  WDS  to  C,C  messages; 

provides  status  information  to  C,C. 

1,400 

0.1 

Prelaunch  Module:  Performs  launcher  parameter 

calculations;  computes  missile  prelaunch 
parameters. 

4,500 

19.0 

Slaved  Illuminator  Module:  Computes  SI  pointing 

parameters;  selects  CWI  frequency. 

1,900 

6.0 

Ship  Motion  Module:  Computes  shipfs  motion 

matrices. 

300 

1.0 

SDC  Input  Module:  Processes  SCD  to  WDS  messages 

300 

0.2 

SDC  Output  Module:  Processes  WDS  to  SDC  messages 

300 

0j2 

Tracking  Illuminator  Module : Computers  TI  point- 

ing parameters;  selects  R F frequency  pulse 
repetition  rate. 

9,000 

20.0 

ATEP 

8,400 

Common  Services 

2,200 

Common  Data 

6,800 

I/O  Buffers 

1,700 

ORTS 

4,900 

ORTS  Overlay  Area 

2,300 
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Fig.  6-9  EDM-1  WDS  Computer  Program  Module  Diagram 
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6. 3. 3. 2 EDM-3C  Weapons  Control  Computer  Program 

The  four  AN/UYK-7  computers  of  the  EDM-3C  WCS  are  host  to  con- 
trol programs  for  SM-2  (or  SM-1)  missile  engagement,  air  intercept  control, 
LAMPS  helicopter  control,  ASW  management,  and  designation  to  other  antiair 
and  surface  Weapon  Systems.  A portion  of  the  FCS  computer  programs  is 
hosted  in  this  AN/UYK-7  suite.  It  also  hosts  the  local  control  programs 
for  ORTS. 

Table  6-4  lists  major  functions  of  the  WCS  computer  programs, 
with  estimates  of  their  use  of  memory  and  processing  time.  Total  mem- 
ory use  is  estimated  at  146,100  words,  including  ATES  and  memory  assigned 
to  local  ORTS. 


TABLE  6-4 

EDM-3C  WEAPONS  CONTROL  COMPUTER  FUNCTIONS 


Functions 

Core 

Time 

(%  of  one  CPU) 

Missile  Engagement  Control  and  Scheduling 

14,600 

8 

AN /SPY-1  Data  Processing  and  Smoothing 

1,700 

32 

Engageability  Computation 

3,400 

2 

C&DS  Interf ace/WCS  Control 

1,700 

1 

Launcher /Illuminator  Management,  FCS  Interface 

5,700* 

51 

Missile  Guidance,  Homing,  and  Evaluation 

4,000 

72 

Air  Control  and  Link  4A  Management 

19,500 

2 

LAMPS  Control 

10,000 

5 

ASW  Management 

8,000 

1 

Support  of  CIWS,  GFCS , Harpoon,  SLCM 

9,600 

— 

Operator  Support  and  Display 

6,900 

5 

Support  Interfaces  (gyro  and  clock) 

2,100 

ATES  (4  CPU's) 

35,800 

(included  above) 

Common  Services 

3,800 

— 

Common  Data 

16,500 

— 

WCS  Allocated  ORTS 

2,800 

— 

*Part  of  FCS. 
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Actual  processing  time  is  strongly  dependent  on  the  number  of 
targets  assigned  and  in  various  stages  of  engagement.  An  estimate  under 
heavy  loading  is  206%  of  a single  CPU  throughput  capacity. 

6.3.3. 3 EDM-3C  Fire  Control  Computer  Programs 

The  AEGIS  FCS  Mk  99  includes  the  slaved  illuminators,  data  con- 
verters, channel  selector,  and  one  AN/UYK-20  computer  for  each  illuminator 
channel.  Fire  control  computer  programs  are  resident  in  both  the  AN/ 
UYK-20  computers  and  in  one  AN/UYK-7  bay  of  the  WCS  computer  suite.  Fig- 
ure 6-10  illustrates  the  FCS  and  its  computer  programs. 

The  AN/UYK-7  computer  programs  are  responsible  for  generation 
^ fire  control  solution,  launcher  positioning  control,  launch  se- 
quence control,  and  missile  prelaunch  control.  The  AN/UYK-20  computer 
programs  are  responsible  for  control  over  the  illuminator  director  state 
and  the  transmitter  state  and  position.  Both  the  AN/UYK-7  and  AN/UYK-20 
computers  are  allocated  ORTS  testing  functions. 

The  AN/UYK-7  fire  control  computer  program  is  estimated  to  re- 
quire 20,000  words  of  computer  memory,  including  the  ATES  and  allocated 
ORTS  for  that  bay.  An  estimate  for  maximum  CPU  loading  is  60%,  includ- 
ing executive  overhead. 


The  AN/UYK-20  computer  programs  are  estimated  to  require  about 
23,000  words  for  slaved  illuminator  control.  Maximum  CPU  loading  in  each 
of  these  computers  is  estimated  at  26%. 

The  AN/UYK-20  computers  will  operate  under  control  of  the  Navy 
standard  SDEX-20  real-time  executive  program.  The  SDEX-20  will  be  aug- 
mented with  a linking  loader  and  with  application-dependent  processes 
such  as  fault  processing,  device  processing,  data  extraction,  and  back- 
ground  self-test. 

^•3.4  Command  and  Control  Computer  Programs 

6. 3.4.1  EDM-1  Command  and  Control  Computer  Program 

The  EDM-1  C,C  program  is  limited  to  support  of  missile  opera- 
tions. It  is  used  to  implement  and  demonstrate  those  command  and  con- 
trol functions  essential  to  the  operation  of  the  AEGIS  Weapon  System. 
These  are: 

1.  Initialization 

Computer  Program  Initialization 
C,C  Readiness 
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Fig.  6-10  EDM-3C  Fire  Control  Computer  Program  Diagram 
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2.  EDM  System  Setup 

Special  Threat  Setup 
Console  Mode  Setup 

3.  Control  and  Operations 

Radar  Direction 
Weapon  Direction 
Special  Points  and  References 
Own  Ship  Position  and  Navigation 
Display  Console  Control 

4.  Tracking 

Radar  Auto  Tracking 

Manual  Tracking 

Tracking  Illuminator  Tracking 

5.  Tactical  Functions 

Identification 
Threat  Evaluation 
Weapon  Assignment 
Engagement  Control 
Time  Management 

6.  Test  Support 

Segment  Control 

Test  Direction  and  Recording 

Figure  6-11  is  a simplified  schematic  of  the  EDM-1  command  and  control 
computer  program  modules.  Table  6-5  lists  the  major  functions  of  each 
module  and  its  use  of  computer  memory.  Total  available  core  is  65,536 
words.  An  additional  14,000  words  of  programs  may  be  overlaid  from 
disk. 


6-29 


6-30 


AN/UYA  4 
Display  Group  i 


State  Modules 
Avail.  States 
EDM-1  Setup 
Sensor  Select 
Display 
Detect/Track 
Test  Director 
T.l.  Control 
Identification 
Idle 

Mode  Select 

Ownship 

CPA 

Special  Points 
AEGIS  Tact.  Coord. 
MSS/EC 
Test  Control 
Sensor  Supervisor 


.All 

Modules 


Tracking 

Periodic 


Threat 

Evaluation 


Central 

Track 

Store 


Special 

Threat 

Maintenance 


Ownship 

Periodic 


Printer 

Maintenance 


Recorder 

Maintenance 


C,C  Computer 


KCMX 

Interface 


AN/SPY-1 


WDS 


Clock 


Disk 


System 

Control 

Console 


•Printer 


_ Magnetic 
Tape 


•Gyro 

-Log 


KCMX 


Fig.  6-11  EDM-1  Command  and  Control  Computer  Program  Module  Diagram 
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TABLE  6-5 

EDM-1  COMMAND  AND  CONTROL  MODULE  FUNCTIONS 


Module 

Core 

Printer  Maintenance  Module:  Responds  to  recorder  requests 

from  other  modules. 

3,300 

Radar  Performance  Module:  Computes  radar  performance  for 

CRT  display. 

1,400 

Special  Threat  Maintenance  Module:  Processes  and  tests 

for  special  threat  candidates. 

1,300 

Tracking  Periodic  Module:  Reviews  track  performance  for 

tracks;  processes  bumthrough  requests  to,  AN/SPY-1 
radar. 

500 

Weapon  Status  Module:  Processes  weapon-oriented  data  from 

WDS. 

1,600 

Threat  Evaluation  Module:  Computes  and  maintains  threat 

index  on  tracks. 

700 

Console  State  Modules:  A module  is  defined  for  each  operat- 

ing state  of  the  AN/UYA-4  consoles.  These  modules  imple- 
ment the  control  actions  taken  by  the  system  operation. 
EDM-1  has  17  state  modules  as  listed: 

Available  States  State  Module 
EDM-1  Setup  State  Module 
Sensor  Select  State  Module 
Display  State  Module 

Detector-Tracks,  Normal  Operating  State  (NOS)  Module 

Test  Director  NOS  Module 

TI  Control  State 

Identification  State  Module 

Idle  State  Module 

Mode  Select  State  Module 

Own  Ship  State  Module 

Closest  Point  of  Approach  State  Module 
Special  Points  State  Module 

AGEIS  Tactical  Coordinator  (ATC)  NOS  Module  ; 

Missile  System  Supervisor /Engagement  Controller 
(MSS/EC)  NOS  Module 
Test  Control  State  Module 
Sensor  Supervisor  NOS  Module 

11,200 
(sum  of 
state 
modules) 

Periodic  Module  Special  Points:  Updates  position  of  fixed, 

moving,  and  slaved  reference  tracks. 

200 
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TABLE  6-5 

EDM-1  COMMAND  AND  CONTROL  MODULE  FUNCTIONS  (continued) 


Module 

Core 

Periodic  Module  Own  Ship:  Updates  own  ship  heading  data; 

maintains  own  ship  display  and  PPI  lines  and  zones  as 
own  ship  data  is  updated. 

400 

Tracking  Module:  Maintains  position  and  velocity  informa- 

tion on  all  tracks  in  system. 

4,100 

Clock  Interface  Module:  Checks  system  clock  against  CPU 

clock;  responds  to  AN/SPY-1  and  WDS  clock  messages. 

800 

Display  Interface  Module:  Responds  to  messages  from  system 

control  console  and  updates  various  CRT  displays. 

5,900 

KCMX  Interface  Module:  Interrogates  Keyset  Multiplexer 

(KCMX)  for  own  ship  data  and  maintains  smoothed  own  ship 
parameters  in  data  files. 

600 

AN/SPY-1  Interface  Module:  Processes  intercomputer  message 

traffic  between  C,C  and  AN/SPY-1  segments. 

800 

WDS  Interface  Module:  Process  intercomputer  message  traffic 

between  C,C  and  WDS  segments. 

900 

Alert  Maintenance  Module:  Maintains  alert  queue;  displays 

next  queue  at  appropriate  console. 

800 

PPI  Maintenance  Module:  Builds  PPI  output  buffer  for  con- 

soles. 

2,200 

Overlay  Control  Module:  Responds  to  request  to  bring  new 

models  in  from  disk. 

200 

System  Control  Module:  Handles  bookkeeping  responsibility 

for  intersegment  messages. 

2,300 

Recorder  Maintenance  Module:  Processes  recording  control 

requests  from  other  modules. 

300 

6. 3. 4. 2 EDM-3C  Command  and  Decision  Computer  Programs 

The  EDM-3C  C&DS  is  designed  to  support  overall  tactical  direc- 
tion of  the  entire  ship!s  combat  system.  In  addition  to  its  functions 
directly  in  support  of  AEGIS,  it  must  provide  for  the  coordination  of 
other  radars  and  data  sources,  communicate  with  other  units  via  the 
standard  tactical  data  links,  and  support  ASW,  surface,  and  electronic 
warfare  (EW)  operations. 
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Table  6-6  gives  an  estimate  of  the  computer  memory  require- 
ments for  major  C&DS  functions.  Total  estimated  use  of  memory  is 
170,000  words.  CPU  utilization  is  estimated  at  about  220%  of  a sin- 
gle CPU's  capacity. 


TABLE  6-6 

EDM-3C  COMMAND  AND  DECISION  COMPUTER  FUNCTIONS 


Function 

Core 

Sensor  Control  and  Track  Management  (including  central  track 

26,000 

stores) 

Identification 

6,000 

Threat  Evaluation  and  Weapon  Selection 

18,000 

WCS  Interface 

300 

Link  11 

14,500 

Link  14 

3,000 

EW  Control  and  Data  Processing 

4,000 

LAMPS  Data  Processing 

8,000 

Navigation 

2,000 

Surface  Operations 

9,200 

Battle  Short  Control 

1,000 

Operator  Support  and  Display 

21,000 

AXES  (4  CPU  1 s) 

35,800 

Common  Buffers 

6,000 

System  Initialization 

5,000 

Allocated  ORTS 

10,000 

6.3.5  Operational  Readiness  Test  Computer  Programs 

The  ORTS  provides  continuous  testing  and  reporting  of  system 
availability,  automated  fault  isolation,  and  control  of  system  configu- 
rations. ORTS  consists  primarily  of  the  centralized  Test  and  Monitor 
Console  (T&MC) , supplementary  remote  terminals,  data  acquisition  assem- 
blies (located  throughout  the  AEGIS  equipment) , and  the  computer  programs. 
Figure  6-12  illustrates  the  general  structure  of  the  ORTS. 
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Fig.  6-12  ORTS  Computer  Program  Diagram 
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The  ORTS  computer  programs  are  divided  into  Central  ORTS 
(CORTS),  which  is  located  in  an  AN/UYK-20,  and  Allocated  ORTS  (AORTS), 
which  is  distributed  among  all  the  AEGIS  AN/UYK-7  and  AN/UYK-20  com- 
puters. CORTS  provides  overall  management  of  test  operations  and  in- 
terfacing with  the  maintenance  operators.  AORTS  controls  specific  tests 
carried  out  within  the  various  segments  of  the  system. 

CORTS  includes  both  core-resident  and  disk-resident  elements. 
It  is  driven  primarily  by  the  disk- resident  ORTS  data  base.  The  CORTS 
modules  run  in  a non- interfacing  background  mode  and  thus  do  not  figure 
in  critical  CPU  timing.  Table  6—7  lists  the  CORTS  computer  program 
modules,  their  primary  functions,  and  allocation  of  resident  computer 
memory.  The  core  allocation  to  CORTS  is  25,000  words,  including  resi- 
dent common  data  and  non-core-resident  (NCR)  buffer. 


Table  6-7 

CENTRAL  ORTS  COMPUTER  PROGRAM  MODULE  FUNCTIONS 


Module 

Core 

Central  Control:  Schedules  ORTS  tasks  and  maintenance 

actions,  monitors  test  completion,  controls  ORTS  in- 
terfaces, coordinates  T&MC  usage. 

3,400* 

System  Status  Management:  Evaluates  test  results  and 

2,600* 

status  reports,  maintains  test  results  and  system 
status  files,  reports  events  on  historical  tape,  up- 
dates T&MC  status  panels. 

+2,600  NCR 

Input/Output:  Controls  I/O  with  T&MC  and  other  operator 

stations,  analyzes  operator  requests. 

3,300* 

Test  Interpreter:  Decodes,  processes,  and  applies  Test 

Control  Language. 

6,800  NCR 

Test  Amendment:  Creates  modified  test  files  on  disk. 

6,300  NCR 

Initialization  Controller:  Determines  system  configura- 

tion, provides  operator  control  of  initialization 
and  reconfiguration,  configuration  events. 

6,200  NCR 

Keyboard  Decoder:  Decodes  commands  from  T&MC,  and  other 

stations,  validates  legality,  initiates  response. 

2 ,300  NCR 

Reports  and  Displays:  Prepares  reports  and  displays 

from  processed  data  and  disk— resident  templates. 

4,000  NCR 

File  Management  Routine 

700* 

Common  Data 

8,200* 

NCR  Buffer 

6,800* 

*Core-resident 
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Disk-resident  ORTS  may  run  as  high  as  2 million  32-bit  com- 
puter words.  This  includes  NCR  program  modules,  test  schedules,  test 
stimuli,  test  results,  status  records,  test  language  sequences,  message 
display  templates,  initialization/recovery  control  sequences,  and  tran- 
sient data. 


6.4  SOFTWARE  DEFINITION,  DESIGN,  AND  IMPLEMENTATION* 

The  process  of  developing  the  AEGIS  computer  systems  has  been 
derived  from  that  used  successfully  in  AEGIS  EDM-1. 

Development  of  the  system  computer  programs  begins  with  the 
generation  of  a system  specification.  The  system  specification  derives 
from  the  initial  assessment  studies  conducted  by  the  Navy  and  continues 
through  advanced  development.  Basic  requirements  for  the  AEGIS  system 
and  AEGIS  ships  are  stated  by  the  Navy  in  the  Development  Concept  Paper 
(DCP),  Tactical  Operational  Requirements  (TORt  s) , and  Top  Level  Require- 
ments (TLRf s) . The  system  specification  translates  and  refines  these 
general  requirements  into  specific  performance  requirements.  These  in 
turn  are  allocated  to  specific  elements  (subsystems)  of  the  combat  sys- 
tem. 


The  system  specification  contains  the  top-level  combat  system 
functional  design.  MIL-STD-490,  augmented  by  SECNAVINST  3560.1  for  the 
computer  program  specifications,  is  the  discipline  used  to  document  the 
total  system  design  in  a hierarchy  of  specifications.  Each  specifica- 
tion contains  performance  requirements  allocated  from  a specification 
at  the  next  higher  level  in  the  structure.  Each  specification  in  turn 
allocates  requirements  to  a lower  tier  document,  and  each  specification 
contains  the  requirements  for  acceptance  testing  at  the  level  governed 
by  that  specification.  This  discipline  of  recording  the  functional  de - 
sign  (requirements)  in  a hierarchy  of  specifications  is  required  even 
where  the  system  design  is  constrained  by  the  prescribed  use  of  exist- 
ing elements. 

The  development  process  for  AEGIS  software  is  laid  out  in  a 
Computer  Program  Development  Plan.  This  document  was  written  originally 
at  the  start  of  EDM-1  development  and  has  been  periodically  revised.  It 
provides  an  overview  of 

1.  Identification  of  programs  to  be  developed, 

2.  Method  and  facilities. 


*The  material  in  this  section  and  in  part  of  6.5  has  been  adapted  from 
an  article  by  L.  J.  Schipper  and  R.  W.  Howery  of  RCA. 
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3.  Schedule,  and 

4 . Responsibilities . 

Figure  6-13  depicts  the  total  computer  program  development  process. 

6.4.1  Software  Definition 

A key  point  is  that  software  development  is  embedded  in  sys- 
tem considerations.  Thus,  software  definition  begins  with  the  system 
specification  (Item  1 of  Fig.  6-13).  In  accordance  with  MIL-STD-490, 
top-level  system  performance  requirements  are  allocated  to  major  sub- 
systems known  as  elements.  The  AEGIS  combat  system  is  comprised  of 
about  25  elements,  of  which  C&DS , FCS,  and  EWS  are  examples.  For  ele- 
ments already  developed,  the  performance  requirements  are  stated  in 
terms  of  inventory  item  specifications,  e.g.,  AN/UPX-29.  For  those 
in  development,  an  element  level  specification  is  produced,  e.g.,  FCS 
Mk  99  (Fig.  6-13,  Item  2). 

System  functional  definition  via  the  specification  discipline 
is  carried  out  by  the  system  prime  contractor  (RCA)  down  through  the 
system  specification  level,  the  element  level,  and  the  program  perfor- 
mance level.  The  programming  subcontractor  is  involved  starting  at 
the  element  level.  Lead  system  programmers  assist  in  the  generation 
of  the  element  specifications  by  defining  implementation  constraints, 
n. g. , available  computer  resources,  type  of  computer  usable,  memory 
capacity  (core),  and  processing  ability  (timing).  The  contractor  De- 
velopment Team  relationships  are  shown  in  Fig.  6-14. 

Each  element  performance  specification  allocates  subfunctions 
to  either  equipment  or  computer  programs.  At  this  level  of  system  de- 
sign, hardware-software  tradeoffs  are  a major  concern.  In  the  AEGIS 
program,  many  of  these  tradeoffs  were  completed  during  the  EDM-1  phase. 
Those  being  performed  in  the  current  phase  are  mainly  refinements  and 
changes  to  reflect  equipment  design  changes  to  take  advantage  of  new 
technology,  e.g.,  the  ship  attitude  matrix  computer  for  AN/SPY-1. 

Functional  performance  requirements  allocated  to  equipment 
have  been  developed  and  written  into  subelement  performance  specifica- 
tions, e.g.,  the  AN/SPY-1  transmitter  or  the  C&D  switching  and  con- 
version unit.  Functional  performance  requirements  assigned  to  general- 
purpose  computer-based  systems  are  developed  and  written  into  computer 
Program  Performance  Specifications  (PPS) , e.g.,  the  FCS  Mk  99  programs 
(Item  3,  Fig.  6-13).  During  generation  of  the  set  of  PPSTs,  the  remain- 
ing hardware-software  tradeoff  activity  is  completed.  RCA  System  Engi- 
neering generates  the  PPS  for  each  program  with  assistance  from  the 
programming  subcontractors  in  the  form  of  more  definitive  implementation 
constraints.  During  PPS  generation,  close  communication  between  the 
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Fig.  6-13  AEGIS  Combat  System  Computer  Program  Development 
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• Definition  •Simulator 

• System  Design  • Data 

• Technical  Monitor  Reduction 

and  Validation  •ORTS  D/B  GEN 

• C/P  Integration  •ORTS  D/B 

• System  Integration 


• ATEP 

• AN/SPY-1  A 

• WCS 

• C&DS 

• ORTS 

• ADOS 


• FCS 


Fig.  6-14  Computer  Program  Development  Team 
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system  contractor  and  software  subcontractor  system  programmers  is 
maintained  to  assure  complete  and  consistent  specification.  Methods 
used  to  ensure  close  liaison  include  the  following: 

1.  All  programmers  are  located  at  the  AEGIS  Programming  Cen- 
ter facility  at  Computer  Sciences  Corporation  (CSC)  in 
proximity  to  RCA.  The  programming  staff  includes  members 
from  CSC,  Raytheon,  and  the  RCA  Software  Design  Depart- 
ment . In  addition,  office  facilities  have  been  provided 
there  for  RCA  System  Engineering  personnel  to  foster  close 
liaison.  The  facility  includes  office  areas  and  the  Pro- 
gram Generation  Center /Computer  Program  Test  Site  (CPTS). 

2.  Complete  agreement  on  the  PPS  is  assured  by  the  System 
Definition  Request  (SDR)  system.  The  SDR  system  was 
established  during  EDM-1  to  enable  omissions  and  ambigui- 
ties in  the  RCA— furnished  PPS  to  be  stated  in  writing  to 
the  RCA  System  Engineering  staff.  Responses  to  clarify 
or  define  are  returned  in  writing  to  the  problem  origina- 
tor. Resolution  often  requires  a meeting  of  the  partici- 
pants either  at  RCA  or  CSC.  Generation  of  the  PPS  is 
monitored  closely  by  the  Navy  at  regular  In— process  re- 
views. Approval  of  the  specification  by  NAVSEA  Project 
Management  occurs  in  executive  session  at  the  conclusion 
of  the  Preliminary  Design  Review  (PDR) . The  SDR  activity 
continues  at  diminishing  levels  through  the  total  project 
cycle  as  the  means  for  requesting  further  system  defini- 
tion. 

6.4.2  Software  Design 

Concurrent  with  completion  of  the  PPS  for  an  element,  the 
architecture  of  its  program  is  established.  Functions  are  allocated  to 
subprograms  and  relationships  between  subprograms  are  defined.  The  ef- 
(Item  4,  Fig.  6—13) , which  is  a prelude  to  generation  of  a computer 
Program  Design  Specification  (PDS) , is  performed  at  the  Programming  Cen- 
ter by  subcontractor  lead  programmers  with  assistance  from  RCA  project 
and  system  engineers. 

Preliminary  allocation  of  functions  to  subprograms  is  followed 
by  iterative  refinements  until  a definitive  PDS  is  written.  The  program- 
ming subcontractor  generates  the  PDS  (Item  5,  Fig.  6-13);  RCA  System 
®'T8iuT££iring  reviews  and  approves  the  design.  In— process  reviews  are  held 
periodically  for  the  Navy  to  assure  adequate  visibility  of  the  on-going 
design. 

Early  in  the  design  phase,  interprocessor  messages  are  defined 
and  documented  in  the  Interface  Design  Specification  (IDS)  in  accordance 
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with  SECNAVINST  3560.1  (Item  11,  Fig.  6-13).  Changes  to  the  interfaces 
requested  by  the  programming  subcontractor  are  evaluated  and  approved 
(or  disapproved)  by  RCA.  Interfaces  with  existing  combat  system  ele- 
ments are  defined  in  IDS 1 s generated  under  the  auspices  of  the  Navy  Com- 
bat System  Manager.  At  the  Critical  Design  Review  (CDR) , the  Navy  re- 
view is  completed,  approval  is  given  for  release  of  the  design  to  coding, 
and  the  IDS 1 s are  placed  under  formal  control. 

6.4.3  Software  Implementation 

Coding  and  testing  at  the  subprogram  level  and  below  is  car- 
ried out  at  the  Programming  Center.  The  resultant  design  is  documented 
as  coded  in  the  Program  Design  Document  (PDD)  and  the  Data  Base  Design 
Document  (DBDD)  (Item  6,  Fig.  6-13). 

As  coding  and  testing  progress,  several  partial  subprograms 
are  linked  together  (a  "build")  to  evaluate  the  ability  of  the  code  to 
perform  a low-level  subfunction.  Further  into  the  coding  and  testing 
phase,  these  builds  embrace  additional  subprograms  and  involve  a greater 
portion  of  each  to  demonstrate  proper  execution  of  a major  function  asso- 
ciated with  an  element.  Builds  are  established  to  divide  the  computer 
programs  up  into  manageably  sized  tasks.  These  are  functionally  de- 
fined so  that  they  can  support  an  orderly  growth  in  capability  and  can 
interface  with  other  parts  of  the  system  (equipment  or  computer  program) . 
Experience  on  AEGIS  EDM-1  shows  the  majority  of  program  errors  to  be  de- 
sign related  and  not  coding  related,  with  the  major  portion  found  during 
program  testing.  This  multiple  build  approach  attempts  to  find  and  cor- 
rect the  problems  early  in  program  development. 

The  Computer  Program  Development  activity  is  implemented  at 
three  facilities  — the  Program  Generation  Center  (PGC) , the  CPTS , and 
the  Combat  System  Engineering  Development  Site  (CSEDS) . The  PGC  and  the 
CPTS  are  colocated  at  the  Programming  Center  (at  CSC).  The  PGC  consists 
of  the  computers,  peripherals,  and  computer  program  operating  systems 
and  compiler/monitor  system  (CMS-2Y)  that  support  generation  of  computer 
programs  from  programmer  coding  sheets  and  provide  documentation  output 
for  the  programming  design  reviewers  and  eventually  program  maintenance 
personnel.  The  PGC  is  operated  as  part  of  the  computer  program  library 
under  the  supervision  of  both  Configuration  Management  and  Quality 
Assurance.  It  is  a closed  shop,  off  limits  to  programming  personnel  as 
contrasted  with  the  open  shop  used  later  at  the  CPTS. 

Figure  6-15  shows  the  flow  of  program  generation  from  the  pro- 
grammer through  the  definition  and  design  developed  by  the  system  engi- 
neer and  the  subcontractor  lead  programmer,  through  the  computer  program 
source  generation,  the  program  compilation,  and  the  linking  of  program 
elements  that  are  performed  in  the  PGC.  The  test  of  the  computer  program 
and  the  data  reduction  and  analysis  of  the  test  results  for  evaluation  by 
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the  system  designers  and  programmers  are  performed  in  the  CPTS  at  the 
CSEDS.  The  estimated  number  of  compilations  during  the  peak  period 
of  computer  program  development  is  600  per  day  with  the  PGC  running  on 
a 24  hour  day,  7 day  per  week  basis. 


6.5  SOFTWARE  VALIDATION  AND  INTEGRATION 

AEGIS  computer  program  validation  and  integration  is  closely 
linked  to  the  design  and  implementation  process  and  is  conducted  under 
the  same  management  structure.  The  System  Test  Plan  provides  for  the 
phased  approach  to  testing  as  described  in  this  section  and  prescribes 
formal  phases  of  test  and  integration  as  a part  of  the  Government  De- 
sign Review  and  acceptance  of  the  system.  Test  plans  and  procedures 
are  subjected  to  Navy  review  and  approval,  as  are  the  specifications 
which  are  the  basis  for  test  design. 

Important  aspects  of  the  test  and  integration  approach  used 
by  AEGIS  include 


1. 

The  "build  a little,  test  a little,  integrate  a little" 
approach,  reflected  in  program  build  structure  and  phased 
test  sequence, 

2. 

Integration  of  computer  programs  with  equipment  early  in 
the  test  sequence, 

3. 

Development  of  adequate  facilities  for  thorough  land- 
based  testing, 

4. 

Use  of  authenticated  simulators  for  interface  and  perfor- 
mance testing,  and 

5. 

Acceptance  testing  of  individual  elements,  conditional  on 
the  basic  requirement  for  overall  system  operational  per- 
formance. 

6.5.1  Software  Testing 

To  demonstrate  functional  capability  on  a build  basis,  inter- 
faces external  to  the  element  program  build  must  be  physically  present 
or  simulated  with  programs  executing  on  other  computers  (simulators), 
the  Programming  Center,  the  external  interfaces  are  all  simulated  with 
the  exception  of  displays  and  computer  peripherals.  The  simulators 

(Item  10,  Fig.  6-13)  are  analogous  to  test  and  inspection  tooling  in  an 
equipment  frame  of  reference.  These  are  controlled  by  performance  and 
design  specifications  and  flow  charts.  A modular  set  of  simulator  pro- 
grams is  being  designed  and  together  with  the  associated  computer 
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equipment  configurations  will  be  supplied  to  the  programming  subcontrac- 
tors as  verified  replicas  of  the  elements  simulated.  Program  testing 
from  the  build  level  to  the  level  of  a complete  program  for  a single 
element  is  carried  out  at  the  Programming  Center/CPTS.  Again  in  the 
test  planning  and  procedure  phase,  SDR's  are  used  to  request  clarifica- 
tion of  test  requirements  stated  in  the  PPS, 

The  CPTS  is  an  open  shop  test  area  with  an  operational  com- 
puter configuration  and  a simulator  computer  system  to  allow  testing  of 
all  levels  from  individual  element  computer  program  builds  to  the  final 
combat  system  multisystem  computer  test. 

The  development  process  is  documented  by  Computer  Program  Prob- 
lem Reports  (CPPRf s) . A CPPR  is  generated  by  anyone  testing  or  using  a 
computer  program  if  a problem  arises  in  its  operation.  The  CPPR  is  re- 
viewed by  a Computer  Program  System  Review  Board  made  up  of  Computer 
Program  Project  Management,  System  Design,  and  lead  programmer  from  all 
computer  program  subcontractor  disciplines.  The  board  assigns  the  CPPR 
to  an  appropriate  problem-solving  team.  This  team  involves  the  respon- 
sible program  designer  supported  by  the  associated  system  engineer.  The 
problem  is  resolved  by  using  experimental  program  modification,  and 
tested,  using  first  patches  (temporary  program  modification  in  direct 
code)  and  then  recompiled  test  programs.  At  this  point,  a recompiled 
version  of  the  program  is  generated  with  the  changes  separated  and  iden- 
tified in  the  computer  program  source  file.  The  experimental  problem 
solving  includes  tests  at  CPTS  and  at  CSEDS  to  assure  solution  to  the 
problem.  Formal  testing  at  both  sites  of  the  final  recompiled  computer 
program  is  completed  before  the  change  identification  in  the  source 
file  is  reviewed  and  the  final  computer  program  change  is  incorporated 
into  the  source  file. 

6.5.2  Software  Integration 

Upon  completion  of  the  initial  build  testing,  computer  pro- 
gram development  proceeds  along  three  parallel  interrelated  paths.  One 
is  the  continued  addition  of  functional  capability  to  the  individual 
element  program,  the  second  is  the  initiation  of  element  integration 
between  the  computer  program  and  the  associated  equipment,  and  the  third 
is  multisystem  integration  of  sets  of  element  computer  programs.  Design 
adjustment  and  modifications  are  driven  by  all  three  of  these  paths, 
resulting  in  final  element  computer  programs  that  support  the  total  com- 
bat system  interrelated  requirements. 

As  the  third  path  of  computer  program  development,  major 
builds  from  several  elements  are  integrated.  This  is  the  beginning  of 
multisystem  integration  (Item  8,  Fig.  6-13).  For  example,  some  of  the 
joint  functional  capability  of  WCS  Mk  1 and  FCS  Mk  99  will  be  evaluated 
using  a partial  program  for  each.  Interfaces  external  to  this  two- 
element  test  will  be  furnished  by  simulators. 
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Multisystem  integration  will  be  used  (as  in  EDM-1)  to  provide 
an  early  indication  of  design  deficiencies  and  will  proceed  concurrently 
with  development  and  test  of  computer  programs  for  individual  elements. 
Functional  capabilities  of  combined  computer  systems  are  added  in  suc- 
cessive steps  until  the  total  set  of  programs  has  been  integrated.  Ini- 
tial multisystem  integration  is  carried  out  at  the  Programming  Center. 
Later  multisystem  builds  are  taken  to  the  Combat  System  Test  Facility 
for  operation  with  on-site  combat  system  elements.  The  external  inter- 
faces for  these  tests  include 

1.  The  actual  physical  interfaces  for  those  elements  already 
installed  and  checked  out  (e.g.,  the  IFF  system); 

2.  The  interfaces  simulated  by  "hardware"  for  shipboard 
equipment  not  present  at  CSEDS;  and 

3.  Interfaces  simulated  in  other  computers  for  those  systems 
not  ready  for  integration  test. 

Extending  multielement  integration  to  the  test  facility  provides  the 
assurance  of  operation  with  the  actual  interfacing  systems  prior  to  the 
qualification  testing  of  element  programs. 

Integrated  system  tests  are  the  end  product  of  multisystem 
integration.  In  these  tests,  major  builds  for  each  of  the  elements  are 
tested  as  a combined  system  utilizing  all  of  the  external  systems  re- 
quired or  available  for  a particular  system  demonstration.  All  other 
external  interfaces  are  simulated  by  other  computers.  Integrated  sys- 
tem tests  are  conducted  to  demonstrate  a major  facet  of  combat  system 
operation,  e.g.,  AAW  demonstration.  These  demonstrations  are  increased 
in  scope  until  the  total  combat  system  functional  capability  is  achieved 
at  Initial  Operational  Test  and  Evaluation  (IOT&E) . 


6.6  SOFTWARE  ACQUISITION  MANAGEMENT  ORGANIZATION  AND  METHODS 

6.6.1  Organization 

AEGIS  management  includes  the  Navy  project  office  with  its 
supporting  elements  and  the  prime  contractor  organization.  Management 
information  is  summarized  in  Table  6-8. 

Navy  AEGIS  project  management  is  conducted  by  NAVSEA,  PMS-403. 
Technical  and  management  support  to  the  project  office,  in  specific 
areas,  is  provided  by  the  Naval  Ship  Engineering  Center  (NAVSEC)  and 
NAVELEX.  The  Naval  Surface  Weapons  Center  (NSWC)  Dahlgren  is  the  lead 
Navy  laboratory  for  the  system.  Naval  Ship  Weapons  Systems  Engineering 
Station  (NSWSES)  has  specific  responsibilities  for  test  and  evaluation. 
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TABLE  6-8 

AEGIS  MANAGEMENT  INFORMATION 


Program  Status 

Engineering  Development  (ED)  (currently  in 
Navy  evaluation  of  first  engineering  model 
of  two-phase  ED  program) . 

Program  Manager 

NAVSEA,  PMS-403 

System  Contractor 

(Prime)  RCA 

Type  Contract 

Cost  plus  fixed  fee  and  incentive  fee 

Software  Contractors 

CSC,  Raytheon  (RCA  in-house) 

Validation  Agent 

NSWSES 

Maintenance  Agent 

FCDSSA(DN)  (by  letter  of  intent) 

Software  Deliverables 

Operational  program  (3  systems) 
Compiler-monitor  system 
Executive  program  (common) 

Software  test  and  evaluation  program 
Operational  training  program  (5  systems) 
Operational  readiness  test  program 

Integration  Agent 

NAVSEA,  PMS-403 

Fleet  Combat  Direction  System  Support  Activity,  Dam  Neck  (FCDSSA(DN)) 
provides  support  with  respect  to  eventual  operational  use  and  mainte- 
nance. 

A NAVSEA  Technical  Representative  Office  is  maintained  at  the 
system  prime  contractor’s  facility  in  addition  to  the  normal  Defense 
Contract  Administration  Services  Offices  (DCASO) . A Naval  Training 
Unit  is  also  at  the  site. 

APL/JHU  has  served  as  technical  advisor  to  the  project  office 
since  the  inception  of  the  project.  Technical  support  has  also  been 
provided  by  a number  of  contractors,  including  Vitro,  System  Consul- 
tants Incorporated,  Bird  Associates,  COMPTEC,  Auerbach,  and  others. 

Computer  system  specialists  have  been  located  on  the  Project 
Manager’s  staff  and  at  the  Technical  Representative  Office,  with  both 
technical  and  managerial  responsibilities.  This  has  served  to  help 
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focus  attention  as  necessary  on  computer  system  development  throughout 
the  growth  of  the  system. 

Organization  of  the  prime  contractor  and  subcontractors  for 
software  development  was  summarized  in  Fig.  6-14  and  discussed  in  Sec- 
tion 6.4. 

6.6.2  Technical  Management  Methods 

6.6. 2.1  EDM— 1 Design  Audit  and  Review 

AEGIS  computer  program  management  has  emphasized  the  defini- 
tion of  computer  programs  as  deliverable  configuration  items  and  the 
documentation  of  this  definition  by  a set  of  uniform  specifications. 

The  specified  requirements  form  the  basis  for  formal  technical  reviews 
throughout  the  design  and  development  of  each  computer  program.  Con- 
currently, the  specification  test  requirements  are  the  basis  for  sub- 
sequent test  planning  documentation  and  testing.  The  technical  re- 
views, PDR,  CDR,  and  Configuration  Audit  Review  (CAR)  are  configuration 
baseline  management  and  contractual  milestones. 

1.  Preliminary  Design  Review 

The  PDR  is  a formal  technical  review  of  the  definition  of 
functional  performance  requirements  for  a computer  pro- 
gram. The  PDR  is  accomplished  either  prior  to  or  very 
early  in  the  design  phase  to  establish  the  system  com- 
patibility of  the  computer  program  allocation  and  the  gen- 
eral design  approach.  The  primary  product  of  a PDR  is  the 
establishment  of  the  documented  computer  program  perfor- 
mance  baseline. 

The  documentation  establishes  the  functional  allocation 
and  interface  relationship  of  the  computer  program  to 
other  system  equipment,  computer  programs,  and  facilities 
to  the  level  of  detail  necessary  to  identify  the  functional 
interfaces . 

2.  Critical  Design  Review 

The  CDR  is  a joint  Navy/contractor  review  conducted  to 
assure  suitability  of  detailed  design  as  depicted  by  speci- 
fications, drawings,  and  data  that  demonstrate  the  design 
approach.  For  a computer  program,  the  CDR  is  a formal 
technical  review  of  the  design  of  the  computer  program. 

The  computer  program  CDR  will  result  in  formal  identifica- 
tion and  approval  of  the  specific  computer  programming 
documentation  that  will  be  released  for  coding  and  testing. 
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The  status  of  outstanding  action  items  will  be  considered 
and  their  impact  on  the  totality  of  the  CDR  established. 
Successful  completion  of  the  specific  CDR  shall  result  in 
approval  of  the  Computer  Program  Design  Specification. 

The  accomplishment  of  this  milestone  signifies  formal  ap- 
proval to  proceed  with  the  coding,  debugging,  test,  and 
evaluation  of  the  computer  program.  The  final  issue  of 
the  specification  is  then  published  and  placed  under  con- 
figuration control. 

3.  Configuration  Audit  Review 

CAR  is  conducted  for  the  engineering  development  model  to 
verify  that  it  is  built  in  accordance  with  its  specifica- 
tions and  drawings;  that  the  results  of  tests  meet  speci- 
fied requirements;  that  these  requirements  as  allocated, 
individually  and  in  total,  support  and  meet  the  require- 
ments of  the  AEGIS  system;  and  that  authorized  changes 
have  been  properly  incorporated. 

The  objective  of  CAR  is  to  assure,  at  the  model  stage  of 
development,  that  the  evolving  design  and  equipment /com- 
puter programs  are  responsive  to  the  mission  requirements 
as  established  in  AEGIS  system  specifications. 

6. 6.2.2  Configuration  Management 

Configuration  Management  is  comprised  of  Configuration  Identi- 
fication (specification  documentation  management,  configuration-item  in- 
ventory), Configuration  Control  (document-change  control,  ECP  processing, 
SCN  issuance),  and  Configuration  Status  Accounting  (reporting  on  status 
of  configuration  items,  including  changes). 

Configuration  Management,  as  applied  to  the  computer  programs, 
is  concerned  with  the  identification  of  and  accounting  for  specific  con- 
figurations of  computer  programs.  These  configurations  may  differ  either 
in  the  inclusion/exclusion  of  their  member  programs  or  in  their  form. 
Variation  in  both  configuration  and  configuration  items  is  reflected  in 
the  corresponding  computer  program  documentation  variations  which  are 
formally  maintained.  To  ensure  reproducibility  it  is  essential  to  iden- 
tify the  specific  media  (card  decks,  tape  reels,  etc.)  that  contain  the 
computer  program  corresponding  to  specific  documentation.  All  deliver- 
ables, both  configuration  and  data  items,  must  be  kept  in  correlation  so 
that  it  is  possible  at  any  time  to  supply  a specified  version  of  a com- 
puter program  together  with  its  formal  documentation. 

At  predefined  stages,  certain  documents  and  computer  programs 
are  placed  under  formal  configuration  control.  At  each  such  stage, 
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generally  corresponding  to  a formal  design  review,  a "baseline"  is  estab- 
lished. For  AEGIS,  these  are  the  Functional  Baseline,  Allocated  Baseline, 
Product  Configuration  Baseline,  and  Preliminary  Product  Baseline,  and  are 
defined  by  appropriate  documents.  Any  change  that  affects  any  of  these 
documents  or  any  change  in  the  computer  programs  after  formal  configura- 
tion control  has  been  established  alters  the  corresponding  baseline  and 
is  thus  subject  to  formal  Engineering  Change  Proposal  (ECP)  procedures 
in  accordance  with  MIL-STD-480.  Approved  changes  are  formalized  by 
Specification  Change  Notices  (SCNfs)  in  accordance  with  MIL-STD-490. 

6.6.3  Computer  Program  Development  Aids 

The  development  of  the  AEGIS  computer  program  involves  a com- 
plex of  many  design,  test,  and  integration  activities.  A means  of  con- 
trolling the  development  process  throughout  the  life  of  the  computer 
program  from  coding  to  delivery  is  required  as  well  as  the  early  design 
control  activities  and  the  test  planning  and  approach.  Techniques  which 
have  been  used  to  enhance  visibility  and  assist  in  development  control 
include  the  following: 

1.  Maintenance  of  computer  program  management  information  in 
a Management  Information  Center  (MIC) , 

2.  Use  of  the  Functional  Flow  Diagrams  and  Descriptions  (F^D^) 
documentation  technique  for  design  audit  and  review, 

3.  Use  of  the  Threads  technique  for  computer  program  imple- 
mentation audit  and  testing,  and 

4.  Design  and  documentation  of  key  tests/scenarios  using  a 
Test  Information  Sheet  (TIS)  control. 

6. 6. 3.1  Management  Information  Center 

The  MIC  is  in  one  room  located  at  the  prime  contractor  and 
directly  contributes  to  computer  program  development  control  by  provid- 
ing insight  into  the  following  areas: 

1.  Maximizing  the  visibility  of  current  programming  activity; 

2.  Providing  direct  information  on  principal  system  inter- 
faces ; 

3.  Providing  reference  data  to  simplify  evaluation  of  designer 
schedule  changes;  and 

4.  Indicating  potential  problems  resulting  from  unplanned 
events . 
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The  major  MIC  elements  are 

1 . Computer  Program  Configuration  Diagrams 

These  block  diagrams  describe  the  general  logic  of  all  in- 
termodule and  intersystem  messages  and  tables,  as  well  as 
interfaces  between  modules  and  external  equipment. 

2 f Configuration  Status 

Charts  are  used  to  report  the  latest  estimate  of  storage 
and  timing  utilization  for  each  AN/UYK-7  computer.  Charts 
are  also  used  to  indicate  the  status  of  each  source  docu- 
ment (current,  pending  changes,  reissues,  etc.)  affecting 
computer  program  control  elements.  These  charts  are  up- 
dated on  a continuing  basis. 

3 . Performance  Activity 

Charts  are  maintained  and  updated  on  a weekly  basis  dis- 
playing current  and  past  utilization  of  all  AEGIS  com- 
puters. Statistics  are  prepared  indicating  the  effective- 
ness of  the  utilization  in  terms  of  use  versus  availabil- 
ity. AN/UYK-7  reliability  as  measured  by  mean  time  be- 
tween failures  and  total  time  used  are  charted  and  updated 
on  a biweekly  basis. 

6. 6. 3.2  Management  Tools 

Two  management  tools  that  have  been  used  successfully  to  in- 
crease visibility  in  the  audit  and  review  process  are  F2D2  and  Threads. 

F2D2  was  developed  by  RCA  to  depict  the  AEGIS  system  at  differ- 
ent levels,  or  tiers,  of  functional  detail.  It  translates  the  require- 
ments of  the  AEGIS  Weapon  System  into  hierarchically  ordered  functional 
block  diagrams  and  associated  textual  descriptions  at  every  level  of  sys- 
tem operation.  Inputs  to  each  block  and  their  sources  are  identified, 
as  are  outputs  and  their  destinations.  Required  functions  are  indicated 
and,  at  lower  levels,  allocated  appropriately  to  computer  programs,  equip- 
ment items,  or  operator  stations.  At  every  level,  traceability  is  pro- 
vided to  higher  and  lower  levels.  At  the  lower,  more  detailed  levels, 
direct  reference  is  made  to  specific  paragraphs  within  specification  and/ 
or  design  documents.  This  enables  a complete  system  audit  by  making 
all  functions  traceable  to  approved  documentation  and  all  documentation 
traceable  to  allocated  functions.  This  multilevel  representation  show- 
ing system  and  subsystem  interrelations  and  interfaces  thus  provides  the 
visibility  to  ensure  that  all  functions  have  been  incorporated  into  the 
design  and  that  the  design  is  in  accordance  with  the  system  specifica- 
tion. 


6-50 


THE  JOHNS  HOPKINS  UNIVERSITY 

APPLIED  PHYSICS  LABORATORY 

LAUREL,  MARYLAND 


Threads,  developed  by  CSC,  is  used  as  an  audit  and  control 
tool  and  also  assists  in  assuring  the  functional  integrity  of  program 
design.  A thread  is  the  path  that  is  traversed  through  system  compo- 
nents in  implementing  a specific  functional  requirement.  Requirements 
are  defined  in  multiple  levels  of  threads,  e.g. , system,  subsystem,  and 
process,  and  Threads  allows  these  levels  to  be  described  in  terms  of 
stimulus  and  response.  Collected  groups  of  threads  become  the  builds 
that  were  discussed  earlier.  The  Threads  technique  also  assists  in  con- 
ducting software/system  testing  since  specific  inserted  checkpoints  can 
be  monitored  along  each  tested  pathway. 

6.6.3. 3 Test  Information  Sheets 

AEGIS  is  using  a combination  of  document  style  and  organiza- 
tion conventions  that  simplifies  the  documentation  of  formal  system  in- 
tegration test  procedures.  The  following  factors  are  taken  into  account: 

1.  Test  requirements  are  known  early  in  the  development  cycle, 
but  details  are  not, 

2.  Specific  tests  become  known  during  the  design  process,  and 
some  only  after  coding. 

3.  Specific  nomenclature,  including  version  numbers  and  media 
identification,  becomes  known  only  as  testing  proceeds. 

4.  Operating  procedures  and  run  specifications  appear  late 
in  the  subprogram/module  development  cycle. 

5.  Many  supplementary  documents,  such  as  ATEP,  I/O  module 
specifications,  and  military  standards,  already  exist  and 
need  reference  only. 

6.  Many  separate  tests  can  be  performed  with  the  same  setup 
(e.g.,  computer  program  and  equipment  configurations)  or 
even  during  the  same  test  run. 

A typical  TIS  outline  (used  for  AN/SPY-1  control  testing)  is  presented  in 
Fig,  6-16. 


6.7  OPERATIONAL  SOFTWARE  MAINTENANCE 

Since  the  AEGIS  Weapon  System  is  currently  in  the  Engineering 
Development  stage,  there  is  no  formal  operational  maintenance  program  at 
this  time. 
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Fig.  6-16  Typical  Test  Information  Sheet  (TIS)  Format 
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6 • 8 HIGHLIGHTS 

Design  of  the  AEGIS  system  was  based  on  extensive  initial 
studies  that  established  system  requirements.  Risk  elements  were 
largely  removed  through  advanced  development  projects  and  competitive 
tradeoff  analyses  prior  to  contract  award.  The  resulting  system  em- 
phasizes modular,  multifunction  operation  controlled  by  integrated 
UYK-7  computer  bays  using  shared  memory  architecture  and  extensive  on- 
line computer-controlled  operational  testing  and  fault  isolation. 

(MP1 ,SE1) 

Required  software  deliverables  in  the  AEGIS  program  require, 
in  addition  to  the  Tactical  Operational  Programs,  a complete  set  of  op- 
erational on-line  and  off-line  test  programs  and  major  support  programs 
(Executive,  Compiler/Operating  System).  (MP3) 

PDR,  CDR,  and  CAR  were  scheduled  at  specific  document  delivery 
points.  These  were  supplemented  by  frequent  in-process  reviews.  (API) 

The  AEGIS  program  required  a Computer  Program  Development  Plan 
as  a contract  deliverable.  This  plan  included  development  approach, 
work  plan,  schedule,  and  assigned  responsibilities.  (AP2) 

Design  control  and  auditing  techniques  employed  included  inter- 
face design  documentation,  Functional  Flow  Diagrams  & Descriptions  (F^D^) 9 
and  program  function  tracing  (Threads).  (SE1,IP1) 

The  TADSTAND  requirements  for  delivery  reserve  in  computer  re- 
sources are  being  applied,  as  well  as  additional  growth  reserves  applied 
to  current  system  sizing  estimates.  In  addition  to  these,  blocks  of 
computer  time  and  memory  have  been  reserved  for  future  support  of  systems 
now  identified  as  future  equipment  for  an  AEGIS  ship.  (SE2) 

Top-down  design  was  employed  in  AEGIS  EDM-1  and  is  planned  for 
the  total  combat  system.  Standards  and  directives  required  in  the  de- 
sign process  included  MIL-STD-490  amplified  by  WS-8506.  SECNAV  Instruc- 
tion 3560.1  will  be  included  in  the  next  phase  of  acquisition.  Documen- 
tation has  been  further  extended  to  include  an  AEGIS  Programmer  Handbook 
setting  forth  rules  and  constraints  for  nomenclature  and  coding. 

(SE3  ,IP2) 

A structured  test  plan  included  program  unit  (module)  testing, 
testing  of  critical  functional  groups  (builds),  segment  testing  with 
simulators,  segment  testing  with  equipment,  and  system  integration  tests. 

(SE3 , IP3) 

Major  AEGIS  facilities  have  included 

1.  Program  Generation  Centers  for  production  and  module- 
level  program  testing. 
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2.  Factory  Test  Site  for  special-purpose  equipment  unit 
testing,  including  initial  operation  under  computer  con- 
trol, where  applicable, 

3.  Land-Based  Test  Facility  for  integration  testing  of  com- 
puter programs  with  the  total  system,  and 

4.  Shipboard  Evaluation  Facility  for  evaluation  of  system 

operation  in  actual  operating  environment.  (IP1,IP3) 

Throughout  the  Engineering  Development  phase  the  Program  Mana- 
ger Office  (PMO)  has  exercised  strong  control  to  ensure  contractor  com- 
pliance with  contract  provisions  relating  to  software  design  and  inte- 
gration and  test  requirements  with  the  hardware  assemblies.  The  Govern- 
ment team  for  system  review  and  contract  monitoring  has  included  com- 
puter system  specialists  in  the  program  office,  the  NAVSEA  Technical 
Representative  Office  (at  the  contractor’s  site),  the  technical  advisor 
(APL/JHU),  the  maintenance  agency  (FCDSSA(DN) ) , and  other  contracted  ad- 
visors. (MS1.MS2) 
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